Lessons From Things That Went Wrong

Founders love talking about success. The launch that went well, the feature that users loved, the metric that exceeded expectations. But the most valuable lessons come from the things that went wrong — and the willingness to be honest about them.

Early in the neart.ai journey, we built a feature based on assumption rather than observation. We assumed that sole traders wanted detailed financial dashboards with multiple chart types, comparison periods, and drill-down capabilities. We spent weeks building a comprehensive analytics dashboard. When we shipped it, usage was minimal. Sole traders did not want analytics — they wanted answers. "How much tax do I owe?" "Am I on track this quarter?" "What expenses have I missed?" The dashboard answered questions nobody was asking.

The lesson was humbling: sophistication is not value. A single number displayed prominently — "Your estimated tax liability is £3,240" — was worth more to our users than an entire dashboard of charts. We rebuilt the interface around direct answers rather than data exploration. Usage increased immediately. The analytics dashboard still exists for those who want it, but it is no longer the centrepiece.

We also learned about the gap between technical correctness and user experience the hard way. Our first implementation of bank transaction categorisation was technically accurate but practically unusable. It presented users with the full HMRC category list — dozens of categories with formal names like "Premises, property and other professional costs" — and expected them to choose the right one. Users froze. Too many choices, too much jargon, too little guidance.

The fix was to simplify the categories into plain English groups — "Office and workspace", "Travel", "Stock and supplies" — and map them to the HMRC categories internally. The tax submission still uses the correct formal categories, but the user never sees them. Technical accuracy is necessary but not sufficient. The interface must meet users where they are, not where the specification says they should be.

A more serious failure involved our initial approach to error handling in HMRC submissions. We treated submission errors as technical failures — logging them, displaying error codes, and asking users to retry. But HMRC error codes are opaque and unhelpful. "Error 403: Business validation error" means nothing to a sole trader. Users panicked, contacted support, and some lost confidence in the system entirely.

We rebuilt error handling to translate every HMRC error into a human-readable explanation with a specific action. "Your UTR does not match HMRC's records — please check the number in your settings" is actionable. "Error 403" is not. This required mapping every possible HMRC error response to a user-friendly message, which was tedious but essential. Error handling is not an edge case — it is a core part of the user experience.

On the business side, we underestimated the importance of onboarding. Our initial assumption was that if the software was well-designed, users would figure it out. Some did. Many did not. They signed up, saw an empty screen, did not know where to start, and left. The software worked perfectly — but only for people who already knew what to do with it.

We built an onboarding flow that guides new users through setup: connect your bank, set your tax year, categorise your first few transactions. This reduced drop-off dramatically. The product had not changed — the introduction to the product had. First impressions matter as much in software as they do in person.

Each of these failures cost time, money, and user trust. But each produced a lesson that made subsequent work better. Building in public means acknowledging these lessons rather than hiding them. The products we build today are better because of the things that went wrong yesterday.