The Roadblocks Were Ours: How We Finally Stopped Waiting and Started Shipping

For a long time, ShellRick Tech existed only as an idea. Not a vague idea — a fairly specific one, with a name, a positioning, a rough product lineup, and a list of the tools we wanted to build. The plan was clear. The capability was there. And yet, months passed without anything shipping.

When we finally sat down and honestly examined why, the answer was uncomfortable. There were no external obstacles. Every barrier between us and starting was something we had built ourselves — a wall of our own construction, dressed up to look like circumstance.

The most persistent self-imposed roadblock was the belief that we were not ready yet. Ready for what, exactly, was always slightly unclear. Ready to build something good enough. Ready to handle the technical complexity. Ready to deal with real users. Ready to commit publicly to something that might not work.

The trap is that readiness, defined this way, is a moving target. Every time you get closer to the threshold you set, you revise the threshold upward. You learn more, which makes you more aware of what you do not know, which makes the gap feel larger rather than smaller. The feeling of not being ready is not a signal that you need more preparation. It is a signal that you are preparing as a way of avoiding the actual decision.

We spent time building mental models of how the products would work, mapping out data structures, thinking through user flows — all of it genuinely useful, none of it the thing that actually needed to happen. The thing that needed to happen was to start building something real and let the actual work do the teaching.

Running ShellRick Tech alongside full-time employment is a deliberate choice, but it was also a source of one of our clearest self-imposed roadblocks: the belief that we needed perfect conditions to start.

The reasoning went like this. We have limited time. Building something rushed with limited time will produce something mediocre. Mediocre products reflect badly on the studio. Therefore, we should wait until we have more time — a longer break between contracts, a quieter month, a stretch of evenings that magically goes uninterrupted.

The flaw in this logic is that perfect conditions do not arrive. They are not a function of the calendar. The quieter month, in our experience, is just as full as the busy one — the nature of the tasks changes, but the available hours do not suddenly multiply. Waiting for ideal conditions is a specific form of waiting forever dressed up as a reasonable strategy.

The productive reframe was to treat limited time as a design constraint rather than an obstacle. If you only have a few hours each week to build something, the product has to be simple enough to build in a few hours each week. That constraint, it turned out, was not a problem. It was the reason our products are clean and focused rather than bloated and overambitious.

One of the less comfortable things to admit is that a meaningful part of the delay was simple fear of shipping something imperfect into the world under a name that was ours.

An internal project or a half-finished tutorial exists in private. A launched product with a domain name and a live URL exists publicly and can be judged. That asymmetry creates a specific kind of resistance — a reluctance to commit to something that can be evaluated and found wanting. It is much easier to be working on something than to have shipped something, because working on something carries no outcome and therefore no verdict.

This is a version of what is sometimes called perfectionism, but it is worth being more precise than that. It was not a drive to make something excellent before releasing it. It was a desire to avoid the vulnerability of having made something at all. The perfectionism framing implies a high standard; the more accurate framing is a low tolerance for being judged.

The resolution was straightforward in theory and difficult in practice: the value of a shipped product, even an imperfect one, is categorically greater than the value of an unshipped perfect one. An imperfect product in front of real users generates real feedback and real improvement. An unshipped product generates nothing except the ongoing cost of maintaining the idea that you are about to do something.

A version of the readiness trap that deserves specific attention is the capital excuse: the belief that you need significant funding or savings before you can start building a software product.

This belief has almost no basis in the kind of products we were building. A web application with a few hundred users does not require significant infrastructure spend. The tools for building, hosting, and operating a small SaaS product or a content site have become cheap enough that the monthly cost of running a live product is genuinely small — often less than a single meal out. Domain registration, a modest hosting tier, and a few software subscriptions are the real upfront costs, and none of them require a business loan.

The capital excuse is especially seductive because it sounds responsible. It dresses up inaction as financial prudence. The honest version of it, in our case, was not a genuine capital constraint — it was an unwillingness to spend even a small amount of money on something before we were certain it would work. Which is a version of waiting for certainty before acting, and certainty is not something you can buy in advance.

The shift from planning to building happened not through a dramatic decision or a motivational breakthrough, but through a deliberate reduction in the scope of what 'starting' meant.

We stopped trying to start ShellRick Tech and started trying to ship one thing. Not the full product vision. Not the polished v1.0. One thing that worked and was live. Quiz Bru was the first product to clear that bar, and the act of shipping it — imperfect, incomplete in some features we had planned, but live and functional — changed the frame entirely.

A live product that does not fully work is fixable. A product that has not been built cannot be fixed. The moment something is live, you have real data: real user behaviour, real error logs, real performance metrics, real signals about what matters and what does not. All of the planning in the world cannot generate those signals. Only shipping can.

After Quiz Bru, the subsequent products shipped faster. Not because the work got easier, but because the template was set. We knew what 'done enough to ship' looked like. We knew that the imperfections in the first version were not permanent embarrassments — they were version one of an ongoing thing. That knowledge made the starting line less daunting on each iteration.

Looking back at the different roadblocks — the waiting-until-ready, the perfect conditions, the fear of judgment, the capital excuse — the pattern underneath all of them is the same. They were all ways of deferring the moment when the idea became real and could be evaluated against reality.

Ideas are comfortable because they cannot fail. A product you have not built cannot get a bad review, attract no users, or turn out to be less useful than you imagined. The idea version of any product is always at its best — fully featured, perfectly designed, beloved by a hypothetical audience. Reality is where ideas get their edges knocked off, and that process, uncomfortable as it is, is the only process through which anything real gets made.

The decision to start ShellRick Tech was ultimately a decision to stop protecting the idea from reality. To accept that whatever shipped would be imperfect, that some products would find their audience slowly and some might not find it at all, and that both of those outcomes were better than the alternative of building nothing.

Every product we have shipped has taught us things that we could not have learned any other way. Not just technical things — though there have been plenty of those — but things about our own decision-making, our own biases, the gap between what we thought users needed and what they actually needed.

RunYourNumbers taught us that a free, genuinely useful tool earns its audience through search, not through launch announcements. KeyForge taught us that constraints are a product feature. Qrop taught us that the same product can serve two entirely different audiences if it is designed with that split in mind. Determine This taught us that specificity is not a limitation — it is the thing that makes a tool actually useful to the people it is built for.

None of that was in the plan. All of it came from shipping. The plan was a starting point; the products themselves were the education.

If we had waited until we were ready, we would still be waiting. The readiness came from the doing, not the other way around. That is the most honest thing we can say about how ShellRick Tech got started — and the most useful thing we know for what comes next.