Skip to main content

Building in Private: Why I'm Not Shipping Until It's Right

· 12 min read
Nathan Riley
Nathan Riley
Lead Developer

"Build in public" has become gospel in the developer community. Share your journey. Get feedback early. Iterate with users. Ship fast, fix later.

I'm doing the opposite. Sigilweaver has been in private development for months, and it won't go public until mid-2026 at the earliest. The GitHub repo is private. I have zero users. And I think this is exactly right for what I'm building.

This isn't contrarianism for its own sake. It's a deliberate strategy for building infrastructure software that needs to be correct on the first try.

TL;DR
  • Early users lock you into bad paradigms - You can't refactor foundations when people depend on them
  • Beta warnings don't prevent pain - Users don't care about disclaimers when their workflows break
  • Infrastructure gets one chance - Sophisticated users won't give you a second look after a botched launch
  • Private building is deep work - No community management, no context switching, just building
  • The launch becomes an event - First impression is the finished product, not the scaffolding

The Paradigm Lock-In Problem​

Here's a concrete example from Sigilweaver's architecture: my current workflow schema is Polars-specific.

Right now, that's fine. Polars is excellent for the use cases I'm targeting - fast, lazy evaluation, reasonable memory footprint. But what happens when I have an engineering team and want to support Spark for distributed workloads? Or Pandas for compatibility with existing codebases? Or DuckDB for in-database operations?

The workflow schema will need to change. Abstractions that made sense for single-engine execution will need to become engine-agnostic. This is a fundamental architectural shift, not a feature addition.

If I had users right now, I'd be stuck. Every workflow they've built encodes assumptions about the current schema. Every integration they've written depends on the current API. Changing it means:

  • Breaking their production pipelines
  • Forcing migration effort they didn't ask for
  • Eroding trust in the project's stability

No amount of "this is beta software, breaking changes can occur at any time" makes users feel better when you break their workflow. They read those disclaimers. They understood the risk intellectually. But when their Friday afternoon is spent debugging why the tool they depend on stopped working, that understanding evaporates.

Private development means I can throw away the entire workflow schema tomorrow and nobody cares except me.

Technical Debt Compounds Publicly​

When you build in public, every architectural mistake becomes social debt too.

In private, refactoring is just:

git commit -m "refactor: completely redesign tool execution model"

In public, that same refactor requires:

  • A deprecation announcement
  • Migration documentation
  • A compatibility shim for the old API
  • Responses to GitHub issues asking why you broke things
  • Updates to every tutorial and blog post referencing the old behavior
  • Patience for Stack Overflow answers that are now incorrect
  • Managing contributors who learned the old API and resist changes

The code change takes a day. The social overhead takes weeks. And that overhead scales with your user count.

This creates perverse incentives: it becomes easier to build around bad decisions than to fix them. You accumulate technical debt because the cost of paying it down includes community management. The architecture calcifies.

Private development means technical debt is just technical debt - not social debt, not trust debt, not documentation debt.

The Feedback Paradox​

"Ship early, get feedback, iterate" sounds reasonable. But there's a trap: early users give you feedback on what exists, not what should exist.

They'll tell you:

  • "This button should be bigger"
  • "Can you add a dark mode?"
  • "The export feature should support Excel"

They won't tell you:

  • "Your core abstraction is wrong"
  • "This architecture won't scale past 10 users"
  • "You're solving a symptom, not the problem"

Users optimize your local maximum. They help you build the best version of what you've already committed to, not the best version of what's possible.

Early feedback pulls you toward incremental improvement when what you might need is a fundamental rethink. And once you have users invested in the current direction, pivoting feels like betrayal.

Private development means I can realize my abstraction is wrong and start over without disappointing anyone.

Competition Sees Your Roadmap​

Your public commit history is a roadmap. Your GitHub issues are a feature wishlist. Your discussions are market research - conducted for free, visible to everyone.

Larger competitors with more resources can:

  • See exactly what you're building
  • Copy it faster with a bigger team
  • Position their marketing against your unreleased features
  • Acquire the space before you launch

You're playing poker with your cards face-up against opponents who have bigger stacks.

This matters more in infrastructure than consumer software. The data tooling space is crowded with well-funded companies watching for emerging patterns. A novel approach visible on GitHub becomes a "feature" in their product six months later, shipped with enterprise support you can't match.

Private development means competitors learn about Sigilweaver when I'm ready, not when they're ready.

The Launch Becomes an Event​

When you build in public, there's no launch. You just... exist. People trickle in, form opinions on half-finished work, and your "launch" is actually "the day you decided to tweet about it."

By then, the narrative is already set:

  • Early adopters have told their colleagues what they think
  • First impressions are based on v0.3, not v1.0
  • The product is "that thing I tried once that wasn't ready"

Private development gives you control over first impressions. The first time anyone sees Sigilweaver, it will be:

  • Feature-complete for the core use case
  • Documented properly
  • Tested thoroughly
  • Polished enough that the experience matches the ambition

The launch is an event, not an accident. The first impression is the finished product, not the scaffolding.

Cognitive Load of Community Management​

Every GitHub issue is a context switch. Every Discord question is an interruption. Every Twitter reply pulls you out of flow state.

When you're solo and trying to build something ambitious, these interruptions compound. You end up spending 40% of your time managing a community for software that isn't done yet. You're answering questions about features you haven't built, explaining workarounds for bugs you haven't fixed, and managing expectations for a roadmap you're still figuring out.

This is the opposite of deep work. It's fragmented attention dressed up as "community building."

I've watched maintainers burn out not because the code was hard, but because the community management was relentless. They shipped something promising, people showed up, and suddenly they had a second job: support engineer for free.

Private development is deep work. No notifications. No expectations. Just building.

The Illusion of Validation​

GitHub stars feel like validation. But what are they actually?

  • People bookmarking "interesting, might try later"
  • Developers who starred based on the README, never cloned the repo
  • Bots and scrapers
  • Competitors watching you

Stars correlate weakly with actual usage and almost not at all with willingness to pay. They're a vanity metric that can trick you into thinking you've achieved product-market fit.

I've seen projects with 10k stars and no commercial traction. I've seen projects with 500 stars and sustainable revenue. The star count tells you nothing about whether you're building something valuable enough that people will pay for it.

Real validation is:

  • Someone using your software in production
  • Someone paying for a commercial license
  • Someone building their business on top of yours

Private development means I'm not chasing vanity metrics. I'll know I have validation when someone writes me a check, not when a number goes up.

Target Audience Sophistication​

Data engineers and ML platform teams are professional skeptics. They've been burned by:

  • Tools that worked in demos but exploded at scale
  • Open source projects abandoned six months after launch
  • Vendor lock-in disguised as convenience
  • "Batteries included" frameworks with dead batteries

These are people who read the source code before adopting a dependency. They check commit frequency. They look at who's funding the project and what the business model is. They evaluate tools rigorously because they've learned that switching costs are real.

A polished v1.0 earns trust. It signals that you've thought things through, that you're serious, that you're in this for the long haul.

A rough v0.3 with "it'll get better!" promises? That gets bookmarked and forgotten. Maybe they check back in a year. Probably they don't.

You get one first impression. With sophisticated users, you don't get a second chance.

Data Science Is Smaller Than You Think​

The data science community is vast. Every company claims to be "data-driven." LinkedIn is full of people with "Data Scientist" in their title.

But the number of people who:

  • Work with data at sufficient scale to need a visual pipeline tool
  • Have the technical sophistication to evaluate tools critically
  • Have budget authority or influence over tooling decisions
  • Are actively looking for a solution in this space

...is actually pretty small. Maybe a few thousand globally? The people operating at the level where Sigilweaver adds value are a niche within a niche.

This means:

  • Word of mouth travels fast (good and bad)
  • A botched launch reaches the whole target market quickly
  • There's no "try again with a different audience" option
  • The reputation you establish early is the reputation you keep

Consumer apps can recover from bad launches. New users show up every day who never heard of the v1 disaster. Infrastructure tools don't get that luxury. The market remembers.

Getting it right once is more important than shipping twice.

The Myth of "Iterate With Users"​

"Ship fast, iterate with users" works for:

  • Consumer apps - Social products, games, content platforms
  • Low-switching-cost tools - Note-taking apps, productivity software
  • Products where "good enough" is acceptable - MVPs solving immediate pain

It doesn't work for infrastructure. Nobody wants to iterate on their data pipeline foundation. They want something that works and keeps working for years. The cost of switching is measured in weeks of engineering time, not minutes of inconvenience.

When I adopt a tool for data infrastructure, I'm making a bet:

  • Will this still be maintained in three years?
  • Will breaking changes be communicated clearly?
  • Can I trust that the next version won't force a rewrite?

These questions matter more than "does v0.1 have the feature I need right now?" A rough early product signals that you don't understand what infrastructure adoption looks like.

Infrastructure software earns trust through stability, not velocity.

When Building in Public Makes Sense​

I'm not saying building in public is always wrong. It works when:

  • Your moat is network effects - Social products need users to have value
  • The learning curve is the product - Educational content, courses, tutorials
  • You're optimizing for community, not revenue - Hobby projects, experiments
  • Switching costs are low - Users can leave easily, so continuous validation matters
  • Speed to market beats correctness - Someone else ships tomorrow if you don't

But none of these describe Sigilweaver. I'm building infrastructure. The moat is correctness and reliability, not network effects. Switching costs are high. Speed to market matters less than not screwing up the launch.

Build in public works when iteration is cheap. Build in private works when getting it right matters more than getting it fast.

The Tradeoffs I'm Accepting​

Private development isn't free. I'm giving up:

  • Early feedback - I might be building the wrong thing
  • Community momentum - No contributors, no evangelists
  • Accountability pressure - No public expectations forcing me to ship
  • Marketing runway - No buzz building before launch

These are real costs. But I've decided they're worth paying.

If I'm building the wrong thing, I'd rather discover that before anyone depends on it. If I need accountability pressure to ship, that's a personal problem to solve, not a reason to involve strangers. If marketing buzz is the only way the product succeeds, it probably wasn't good enough anyway.

The bet: a polished launch in June 2026 beats a rough launch in January 2026 with five months of public iteration.

What Private Building Actually Looks Like​

Day-to-day, building in private means:

  • No notifications - GitHub is just me
  • No roadmap pressure - Features ship when they're ready
  • No documentation theater - I write docs for future me, not current users
  • No support burden - The only tickets are my own TODOs
  • No context switching - Deep work sessions without interruption
  • No vanity metrics - Stars, forks, and watchers don't exist
  • No expectation management - I can change everything tomorrow

It also means working in a void. No external validation. No dopamine hits from notifications. No sense that anyone cares about what you're doing.

That void is uncomfortable. It requires genuine internal motivation, not external accountability. Not everyone has that. I'm not even sure I have it - ask me again after launch.

Private building selects for people who can self-motivate. Public building selects for people who can community-manage.

The Launch Plan​

When Sigilweaver goes public (targeting June 2026), the goal is:

  • Working software - Not a demo, not a prototype, not "coming soon"
  • Complete documentation - Not "docs coming soon" or auto-generated API references
  • Clear value proposition - Obvious why you'd use this over alternatives
  • Business model transparency - Dual licensing, commercial options, sustainability plan
  • Credible commitment - Legal structure, CLA with protections, long-term thinking

First impressions matter. The launch is the handshake. It needs to be firm.

Building in private is a bet on craftsmanship over velocity. It's a bet that infrastructure software earns trust through correctness, not iteration speed. It's a bet that my target audience would rather wait for something right than settle for something fast.

We'll see in June if the bet pays off.

Discuss on GitHub · Email contact@sigilweaver.app · Visit sigilweaver.app