Should Customers Build Your Features?

Customers could build their own features now: not just request them, actually build them. It is feasible today. With AI coding tools, a customer could log into your SaaS, open a chat interface, and say “add a dashboard that shows X.” The AI builds it. A few minutes later, maybe a day for something complex, they get an email: “Your feature is ready.”

This sounds like freedom, but it might be chaos.

Yes, the customer knows their problem best. But many customers will build the wrong thing. They’re not weighing input from your other hundreds or thousand users like you can; they’re not building up a level of product taste over time. They have their own jobs to do.

But it’s an interesting thought experiment. What happens if you actually let them? The cons are easy to determine…but there are interesting pros!

• Customers get exactly what they want, when they want it.

• It eliminates the need for a feature request graveyard.

• It frees up your team to work on the core product.

• Customers know their own problems better than you do.

• It reduces support tickets (people solve their own issues).

• It creates a competitive moat: your product becomes infinitely customisable.

• It surfaces use cases you would never have thought of.

• Customers are bad at describing what they want: specifications get lost in translation.

• ‘Build it yourself’ bypasses the game of telephone.

• They show instead of tell, so you can actually see what they mean.

• You can reverse-engineer their builds to understand their real needs.

• This provides a better signal than feature requests or user interviews.

• Some customers will actually build the right thing.

• They use the product daily, so they know their workflows better than you might.

• Power users notice frictions that you never will.

• People doing the job often know exactly what’s missing.

• Many customers are domain experts. Not all, but many.

• This might only work for straight-forward SaaS interfaces.

• If other companies can do this, they you have no moat.

• Customers might try to turn it into a different product.

• What they ask for may be impossible and/or unreasonable. Puts you in an awkward position of saying not possible.

• Customers build solutions, not solve problems (e.g. the export button versus the actual need).

• There is no visibility into what other customers need; they optimise for themselves.

• They may have no overall “product taste”, that’s not their job and it shouldn’t be.

• Code maintenance is a nightmare. Who owns it when it breaks?

• The product becomes cluttered and incoherent.

• New users are confused by the AI-generated sprawl.

• Too much code to review for your dev team.

• Your biggest customer builds a mission-critical workflow on something fragile.

• If you outsource the process of deciding what to build, what are you?

• Data management headaches: customer-built features touching data in unpredictable ways.

• The real risk is features that create new data structures, query patterns or storage that you didn’t plan for.

• Who pays for the computing power and storage that their unreliable feature uses?

• Data integrity: what if their feature writes bad data that corrupts the rest of the system?

• Audit and compliance nightmare: who approved this code that touches PII?

Companies are starving for genuine customer feedback. Feature requests are vague. Even if you have them, analytics only show what was clicked, not what customers want or need. Most of the time, we end up guessing. Informed guesses, but guesses (or bets) none the less.

Allowing customers to build their own features would send a clear signal; it would be unfiltered and you would see exactly what they are trying to do, not what they say they want, but what they actually need (well…we would hope).

I think the trick would be to treat it like a beta programme.

• The customer builds a feature in a sandbox, but with real data.

• You can then see what they built and why.

• If it’s good, you can properly productise it: maintain it, test it and make it available to everyone.

• If it solves the wrong problem, you now know what conversation to have.

• Either way, you have discovered something valuable.

Customers need our expertise, knowledge and experience in terms of what can be built. However, deciding what to build is not an easy question to answer, and we haven’t historically received much good input from customers. However, if customers could build the features they want just by asking for it, things would become very interesting. Or chaotic.

Or…maybe the answer isn’t “customer builds it themselves.” Maybe it’s “get on a call and build the damn thing together.” Someone with product sense, a screen share, and an AI coding tool. The customer says “I need this report”, you say “like this?” and build it in front of them. Build something in a session, throw it away if it doesn’t work. Label it beta, create it together in a sandbox.

People get upset when Google discontinues a product, but it’s the right thing for them to do. They try to build new things and discard them if they don’t work. The outrage is psychological. The development process is correct. However, allowing customers to build their own features would make this much more difficult. In this case, it wouldn’t just be Google killing Reader: it would be you killing something they themselves had built. Could be a difficult conversation.