Build Fast, Understand First: What Finny Taught Us

We Built Finny Twice. The Second Time We Understood the Problem First

Two common pieces of advice in product development seem to conflict. One says to deeply scope before building. The other says to start quickly because real learning only happens once a product is in use. These are often treated as opposing strategies, but they apply to different parts of the process.

Building Finny taught us that distinction the hard way.

The “Quick” Start That Wasn’t

Finny began as a side project within a larger financial planning tool. At some point, it split off into what seemed like a smaller and faster idea: a tool to create financial plans. The scope felt manageable, so we did limited research and moved quickly into development.

The flaw was subtle. We scoped the solution we had in mind, not the underlying problem. In reality, financial planning was being done in Excel, where accountants had full flexibility to adapt models, adjust assumptions, and reshape structures for each case.

Without explicitly stating it, our goal became to replicate that flexibility in software. Every scenario possible in Excel needed to be supported. That introduced a level of complexity we had not fully understood.

The result was predictable. The system struggled under use cases it was never designed to handle.

Feedback That Exposed the Gap

The feedback from accountants made the issue clear. They were not asking for minor improvements. They were pointing out structural limitations, scenarios the product could not represent because the underlying logic had not been modeled correctly.

It became clear that this was not a matter of adding features. The problem was foundational. We had built quickly on an incomplete understanding.

At that point, the only viable decision was to start over.

Restarting With the Right Focus

The second time, we approached the problem differently. Before writing code, we invested time in understanding how financial plans are actually constructed. We analyzed where flexibility is essential and where it is simply a habit formed by working in spreadsheets.

We focused on identifying the underlying structure behind the many variations Excel allows.

This upfront work paid off significantly. It reduced rework, clarified design decisions, and prevented us from repeating earlier mistakes. Deep scoping is not overhead. It is the most effective way to avoid rebuilding the wrong solution.

Still Moving Fast

Despite this deeper preparation, we did not slow down execution. We still aimed to get a working product in front of users as quickly as possible.

Understanding the problem and discovering the product are different activities. The first can be done through analysis. The second only happens through real usage.

Key features emerged through observation:

• Onboarding evolved from a basic intake flow into an AI-assisted process after seeing users struggle with manual input.

• The chat interface was introduced after observing how users wanted to adjust plans, enabling changes through natural language instead of manual edits.

• Business plan support was added once it became clear that users needed integrated outputs rather than separate documents.

These were not planned features. They were discovered through real interaction.

The Real Lesson

The apparent contradiction disappears once you separate problem and product.

Understanding the problem requires time and depth. It defines the structure and complexity of what you are building. Ignoring this leads to fragile systems and costly rewrites.

Discovering the product requires speed and exposure to real users. It reveals usability, workflows, and features that cannot be predicted upfront.

The first version of Finny was built quickly on a shallow understanding. The second was built just as quickly, but on a solid foundation.

The speed did not change. The understanding did.