New software project? Some shortcuts get you to market faster—and others will sink your ship.

Everyone tells you to collect feedback fast. Everyone tells you that less is more. Everyone tells you the cheapest feature is the one you don’t need and therefore don’t have to build. And you keep hearing that at the beginning you’re allowed to be “quick and dirty” to get your software idea to market fast.

What almost no one tells you: there are two different classes of shortcuts. Both get you to market quickly, but one will make your life hell once things get serious.

Not all shortcuts are malicious…

Here are a few examples of shortcuts that are usually fine:

1. An architecture that’s just good enough right now but probably won’t scale. Of course you don’t build a huge cluster when your only user is still your mom. But as your user numbers grow, you’ll likely recognize the need for scalability early enough and can migrate there in time, step by step.
2. Fake doors. If you want to know whether your target audience is interested in a feature, you don’t build the feature. Instead, you might just build a button and log how often it’s clicked. Based on that data you decide whether to build the feature or not. Some developers start to hyperventilate at the suggestion of a fake door, but as far as I know, no one has died from it.

…but some are

And here are two examples of shortcuts you shouldn’t take:

1. “We’ll do analytics later.” If you can’t see from day one how (and whether!) your system is being used, you make more assumptions than you need to. How much time does a user spend in your flow? How often does a request fail? How often does a user abandon checkout? These are important questions you must be able to answer from the start—and in every ecosystem there are frameworks and vendors that handle the heavy lifting for you.
2. No historical data. As your system is used, user and customer data changes. Fields get edited. Entities get deleted. If you only ever see the current state, you lack critical information about how you got there. You may lose important knowledge, for example when you need to trace a critical bug or when you’re expected to provide customers with historical analyses. You can clean up and delete data once you realize you don’t need it—but reconstructing the past is costly to impossible.

How do you tell whether a shortcut is dangerous?

If you want to assess whether you can take a shortcut, ask yourself these three questions:

1. “How much time am I really saving right now by taking the shortcut?” Are we talking a few hours or several weeks? And how does that number change when it’s time to clean up the shortcut later? Is that just as quick as adding it now? Or does it accrue extra cost over its lifetime?
2. “How likely is it that this decision will catch up with me?” I’ve seen codebases where “quick-and-dirty” hacks celebrated their fifth or even tenth anniversary—sometimes because there was never a need to rebuild them “the right way.”
3. “What’s the worst that can happen if I take the shortcut?” The range of possible answers is wide: from edge cases that will likely never occur to legal consequences if anyone ever looks closely—I’ve seen all of it.

These and other questions help, but they don’t live in isolation. Factors like your product type, target market, and audience can turn simple decisions complex or turn harmless hacks into malignant problems: what might be fine in a B2C mobile app may be a much bigger risk in a B2B backend with payment processing.

What if you can’t answer these questions?

Maybe you didn’t even realize until now that these questions matter. Maybe you’re now at the point where you don’t know how to answer them. That’s good, because you’ve moved a step forward. Until now, you didn’t know what you didn’t know. Now you know what you don’t know.

The crucial question that you—and only you—can answer: Do I have the budget to pay tuition for learning the hard way? Do I have time for experiments, and do I trust that I or my team can react quickly enough if things catch fire? Or do I draw on the experience of people who have already made these mistakes?

In my daily work I often hear lines like: “I’ve done that before, and it usually ends badly.” Or: “If we do this, we should expect to clean it up within a quarter at the latest, and I don’t know if the time saved now is worth it.” And since I’ve been developing software professionally for more than seven years now, I often say these things myself.

Insights like these can save you weeks of work and tens of thousands of euros—and suddenly two extra days feel like the best bargain of the month.

Can you imagine that this experience could help with your current project? Then let’s talk—no obligation, relaxed, and whenever it suits you: Pick a time on my calendar.