Why Discovery Is the Most Expensive Thing You'll Ever Skip

We wanted to help small businesses be more sustainable. That was the starting point for stepzero.eco, a sustainability action platform for UK SMEs that we designed and built at Teckollab. The market clearly needed it, and the brief felt ready to build against.

But we have spent enough time rescuing projects and inheriting codebases to know what happens when teams skip the thinking and jump straight into code. The pattern is always the same: three months of confident development, then a creeping realisation that the architecture does not support what users actually need, followed by a painful rewrite that costs more than the original build. So we applied the same discipline to stepzero.eco that we would to any product we build. We started with discovery, not development.

That decision shaped everything that followed.

The idea sounded simple. It wasn't.

On the surface, the brief was clear enough: build a platform that helps small businesses take practical sustainability action. Not carbon accounting software, not a compliance tool, but something that could tell a bakery owner or a freelance designer what they can actually do right now to reduce their environmental impact.

The complexity only becomes visible when you sit with the problem for a while. A bakery and a design studio have almost nothing in common when it comes to sustainability. A manufacturing business cares about supply chain materials and energy consumption, whilst a professional services firm cares about travel, commuting, and office energy. A food business cares about waste, water, and sourcing. The more we looked at the problem, the more it became clear that "sustainability advice for small businesses" is not one problem at all, but dozens of overlapping problems that share a common language but diverge completely in practice.

Through the discovery process, we identified 8 core sustainability focus areas: Energy, Waste and Recycling, Water, Travel and Transport, People and Wellbeing, Community and Giving Back, Suppliers and Materials, and Carbon Reporting. Each of these applies differently depending on the industry, the size of the business, the type of premises, and how the operation runs day to day. That gave us 13 distinct business types to consider, with priorities that barely overlap between them.

A one-size-fits-all action list would have been useless. Show a freelance consultant tips about reducing factory water usage and you have lost them before they have finished reading the first recommendation. The product had to feel like it understood who you are and how you operate, or it would feel like every other generic sustainability resource already gathering dust on the internet.

The matching engine nobody planned for

Nobody sat down at the start of the project and said "we need a personalisation engine." That requirement emerged entirely from the discovery work, and it ended up becoming the heart of the product.

When we mapped out how sustainability actions relate to different business profiles, we found that matching the right actions to the right business requires considering a surprising number of variables: industry type, operating model, whether you own or rent your space, how large your team is, whether you operate vehicles, whether you ship products, and several more. The relationships between these variables are not always obvious either. A business that rents its premises has almost no control over building-level energy decisions, which means an entire category of actions becomes irrelevant, but that same business might have significant influence over waste, travel, and procurement decisions that a property-owning business would approach completely differently.

The matching engine that came out of this analysis is what separates stepzero.eco from a well-organised blog post. Without it, we would just be presenting a static list of 230 sustainability actions. Discovery also exposed a dependency that would have been easy to miss. The onboarding flow had to collect the right information to feed the matching engine, which meant every question asked during signup needed to exist for a reason. These were not profile questions for the sake of completeness. They were the exact inputs that determine which of those 230 curated actions are relevant to each business. Getting the onboarding wrong would have undermined everything downstream, and we would not have known that without spending the time to understand how all the pieces connected before writing any code.

Without proper discovery, none of this architecture would have been visible until well into development, at which point changing it would have meant rewriting the information model, the onboarding flow, and the matching logic after launch. That is the kind of rework that quietly doubles a project's timeline and budget, and it is almost always avoidable.

What discovery produced

The discovery phase shaped four foundational decisions that carried through the entire build.

The information architecture was designed around the personalisation requirements rather than a generic "business has actions" data structure. Actions carry matching criteria, businesses carry profile data, and the engine connects them. This sounds straightforward in hindsight, but we have watched plenty of teams default to a simpler data model and pay dearly for it when personalisation needs surface later. The matching logic itself was designed, documented, and validated before we wrote any production code, so we knew exactly what it needed to do and what information it needed to work with. Every screen in the onboarding flow maps directly to the personalisation engine, which means nothing in the signup process is decorative. And the phasing strategy came directly from discovery too: it told us what to build first (curated action matching), what to build second (AI-generated suggestions for gaps in the library), and what to defer entirely. The first release delivered real value on day one rather than shipping a half-built version of everything.

The bigger picture

Discovery is not a delay. It is insurance against building the wrong thing, and the cost of getting it wrong dwarfs the cost of spending a few weeks understanding the problem properly. For stepzero.eco, skipping discovery would have meant discovering these architectural requirements after launch rather than before it, and that is the kind of mistake that compounds quickly because every feature you build on top of a flawed foundation inherits that flaw.

We have also found that discovery surfaces the questions that matter most. "How many business types do you need to support?" is a more useful starting question than "what colour should the button be?", and yet the instinct is almost always to start with the visible layer rather than the structural one. The value of stepzero.eco is not that it lists sustainability actions, because hundreds of websites already do that. The value is that it shows the right actions to the right business, and that specificity only emerged because we invested in understanding the problem before we started solving it.

If you are at the beginning of something and wondering whether you can afford to spend time on discovery, the more honest question is whether you can afford not to. Every project we have seen that skipped this step ended up doing it anyway, just later, under pressure, and at three times the cost. The teams that invest in understanding the problem before solving it do not just build better products. They build them faster, because they are not constantly unwinding decisions they made before they understood what they were building.

This is the first post in a series about how we built stepzero.eco. Next, we will get into how we cut our onboarding from 15 questions to 5 without losing the personalisation data that powers the entire product. If any of this resonates, or if you are working through similar questions on your own product, we are always up for a conversation. Drop us a line.