What I got wrong, and what it cost

The most expensive mistakes in this company have not been dramatic outages. They have been assumptions that looked efficient at the time and later required work across code, copy, design and compliance.

I cannot attach a useful financial number to each decision. The cost was rework, lost focus and a longer route to a product whose boundaries could be explained accurately.

Writing this is not an attempt to turn mistakes into a founder performance. It is a record of decisions I would sequence differently now.

I started with too much product

The early idea tried to answer several different money problems at once. Features accumulated because each one sounded connected to the previous one. A broad assistant, budgeting tools, documents and other workflows could all fit under a loose idea of helping with money.

The result was not a larger coherent product. It was several products sharing screens and a name. Each feature brought different data, support questions and public claims.

Narrowing the company to connected budgeting required removing work, not simply adding a clearer homepage. Old routes, metadata, screenshots and descriptions had to be found. Some technical identifiers could not be renamed immediately without creating risk elsewhere.

The cost was a large clean-up that would have been smaller if the first problem statement had been stricter.

I treated naming as a design task

The product name was chosen before trademark risk had been investigated deeply enough. A conflict later made another rename necessary before launch.

A name appears everywhere: domains, app configuration, email, metadata, legal wording, images, store records, internal identifiers and user expectations. Changing it is not a logo exercise. Some places can change quickly. Others need migration, review or a compatibility period.

The cost was another round of replacement work and the knowledge that public articles needed to survive a name change. That is why these posts use topic-based URLs and minimise the product name.

I would now treat name clearance as infrastructure work. It belongs early, before a public identity spreads through the system.

I underestimated how much compliance is product work

At first, I thought of regulation as a set of documents around the bank connection. The documents matter, but the harder work is making the product behave like the documents say it behaves.

Consent wording depends on the data flow. Complaint wording depends on the principal relationship. A statement about deletion depends on databases, backups and provider processes. A claim about read-only access depends on the actual permission and every user-facing action.

The cost of treating these as separate tracks was revisiting architecture and copy after decisions had already spread. It also made reviews slower because the evidence was not organised around the live journey.

I built before defining the failure states

A successful bank connection is easy to draw. Real use includes expired consent, an unsupported account, delayed transactions, duplicated pending records and a bank returning partial information.

When failure states are added late, the interface has nowhere to put them. A number appears current when it is stale. A retry button cannot explain whether another consent is needed. Support has to infer which stage failed.

The cost was rewriting flows that looked complete in a demo but did not explain their own uncertainty. Now the failure state is part of the feature definition rather than a message added at the end.

I confused visible progress with important progress

A new screen is easy to show. Access review, provider due diligence, logging and a deletion test are less visible. That made it tempting to prioritise the thing that produced a screenshot.

In a bank-connected product, invisible work often determines whether the visible feature can operate responsibly. Delaying it does not remove it. It concentrates it near registration or launch, when changes are harder.

The cost was context switching and rushed documentation. I now treat controls, support and public explanations as part of the feature, not a separate queue.

I let old copy outlive old decisions

The company changed product direction and pricing more than once. Old claims remained in static pages, structured data, metadata and generated build output after the main screen had changed.

This matters because search engines and users can land on those surfaces directly. A correct React component does not cancel an incorrect prerendered page.

The cost was repeated repository-wide audits. It also led to a better rule: a product change includes every public representation, including files that are generated at build time.

What I would keep

Some early decisions held up. Read-only account access fits the product problem. Using a regulated principal creates necessary oversight. Keeping the assistant optional prevents generated text from replacing inspectable transaction data.

The lesson is not that every first decision was wrong. It is that confidence needs a test. Product scope needs a sentence. A name needs clearance. A data claim needs a map. A control needs evidence.

The company is more focused because of the corrections, but the corrections were not free. They consumed attention that could have gone into testing the current product. That is the honest cost, and it is why I now value a narrow, defensible decision over a broad idea that only looks fast.

For current service details, read the company's open banking explanation and Privacy Policy.