Most software products are described by their features and defeated by everything else. Here is the honest shape of what building one involves.
The features are the smaller half
Whatever your product does, it also needs all of this before anyone can pay for it:
Accounts and organisations. Not just users — companies containing users, with roles, invitations, someone who can remove a colleague, and a sensible answer for what happens when the account owner leaves.
Billing. Subscriptions, trials, upgrades, downgrades, failed payments, refunds, VAT handling, invoices that satisfy an accountant. Payment providers handle the transaction; the logic around it is yours.
Onboarding. The gap between signing up and getting value. Products lose most of their trial users here, and it is rarely designed with the same care as the core feature.
Notifications. Email that reaches the inbox rather than spam, which means proper authentication — see SPF, DKIM and DMARC explained — and preferences so people can turn things off.
Support. A route for customers to reach a person, and someone whose job it is to answer.
Security and data protection. Access control, encryption, backups, a data retention policy, a way to export and delete a customer's data on request. Business customers will ask, and increasingly they will send a questionnaire.
Observability. Knowing the system is up, knowing when something failed, and being able to investigate a customer's report. Without this you learn about outages from customers.
Make the first version narrower
The instinct is to launch with enough features to compete. The better move is to launch with one workflow that works completely, for one type of customer.
Two reasons. First, you do not yet know which features matter — you have opinions, and opinions are cheaper to test with a real product than with a specification. Second, every feature added before launch delays the day you start learning.
Ask what the single thing is that a customer would pay for if the product did nothing else. Build that, plus accounts and billing. Everything else goes on a list you revisit after twenty customers have used it.
The first version's job is not to be complete. It is to be narrow enough that you find out quickly whether you are building the right thing.
Decisions to make before writing code
Who exactly is it for?
"Small businesses" is not an answer. "Independent lettings agents managing between twenty and two hundred properties" is. The narrower the definition, the easier every subsequent decision becomes — including the marketing, which is usually harder than the build.
What does it replace?
Every new product displaces something: a spreadsheet, a competitor, or doing nothing. Knowing which determines your pricing, your onboarding and your sales conversation.
Displacing "doing nothing" is the hardest of the three and the most commonly assumed to be easy.
How will customers get their data in and out?
Import is an adoption question — if moving in takes a fortnight, most prospects will not. Export is a trust question, and business buyers ask about it.
Single tenant or multi tenant?
Almost certainly multi tenant, meaning all customers share one system with their data separated. It is dramatically cheaper to run and to update. The separation must be enforced properly, which we cover in multi-tenant explained.
What are you obliged to do with personal data?
If customers store personal data in your product, you are a processor under UK GDPR. That means a processing agreement, a lawful basis, security measures, breach notification and clarity on where data is held. This is not optional and it is easier to build in than to retrofit.
The ongoing cost
The build is the beginning. Budget annually for:
- Hosting, which grows with customers
- Third-party services — payments, email, monitoring, error tracking
- Security updates and dependency maintenance
- Support, which scales with customer count
- Continued development, because customers ask
A reasonable planning assumption is that the first year after launch costs a substantial share of the build again. Products that skip this run into a slow decay where nothing is broken but nothing improves either.
Signals it is going well
Not sign-ups. Sign-ups are easy to generate and tell you nothing.
Watch instead: how many trial users reach the point of value; how many are still active after thirty days; how many convert to paying; and how many are still paying six months later. That last figure decides whether you have a business.
Talk to the ones who leave. They will tell you what is wrong more usefully than the ones who stay.
If you are commissioning rather than building
Own the code and the hosting outright, insist on documentation and tests, use conventional technology so others can pick it up, and keep the data exportable. A product you cannot move away from is not an asset you fully own — see avoiding lock-in.
Our web applications team builds software products for UK businesses, starting from the narrowest useful version. Discuss your requirements and we will tell you what the first release should and should not contain.
