I Named My Company After My Daughter. Now I'm Building Something Worthy of Her Name.

Nire is Erin spelled backwards. She is six. The pink in the brand is her favourite colour. This is a personal account of what it actually took to build two B2B SaaS products in four weeks, without writing a single line of code directly, and why the standards I held to throughout matter more than the speed.

I did not name the company after her because it was a nice story to tell investors. I named it after her because I wanted to build something that outlasts me. Something she might look back on one day and understand why her dad disappeared into his laptop for months.

That felt like the right kind of pressure to build under.

I am not a developer. I have spent my career in product, leading builds across backend systems, telephony platforms, mobile apps, desktop apps and web products. I have been in the rooms where the hard technical decisions get made. I understand the shape of those decisions, even when I am not the one making them. Beyond a little Ruby on Rails years ago, I have never written production code myself.

What I had never done was build something alone. No team, no engineering department, no one to hand a brief to. Just me, a clear problem, and an AI coding tool I had to learn to use properly.

What is Nire?

Years of strategy work sitting across the table from PE firms and VC funds left me with two problems I could not stop thinking about.

Fund managers trying to understand how their investments were actually performing, stuck between spreadsheets and enterprise platforms priced out of reach for most funds. And founders walking into those same rooms completely unprepared, no honest self-assessment, no benchmark, no real sense of how they would be evaluated.

Two broken halves of the same system. Nire is built for both.

Fund managers get a proper portfolio platform built to replace the spreadsheet, at a price point that makes sense for most funds. Founders get an honest investability assessment across eight dimensions, with a scored report they can actually act on. With their consent, their profile feeds directly into fund manager deal flow.

Each side makes the other more valuable. That was the point from the start.

What the build actually taught me

The most important decision I made before writing a single line of product code was to write a document called CLAUDE.md. It started as a set of rules for how the AI coding tool should behave. It became something more valuable: a living record of every lesson learned the hard way, encoded as a rule so it could never be forgotten mid-session. When a bug revealed a gap in how database constraints were documented, the fix went into the product and the rule went into CLAUDE.md. When a test pattern caused CI timeouts, the better pattern replaced it and the rule was written down. By the end it was not just instructions for a tool. It was the institutional memory of the entire build.

Diagnose before acting, every single time without exception. No implementation until a written diagnosis had been produced and approved. It felt slow. It was not slow. Every time that rule was followed, problems were caught before they became bigger problems. Every time the temptation to skip it won, something went wrong. The rule stayed.

Testing deserved the same respect. Writing tests first, confirming they fail, then implementing is not a bureaucratic process. It is the only honest way to know whether your tests actually test anything. A test written after the fact proves nothing. When the test suite started slowing CI down it was partitioned by product surface so a change to the founder flow did not run fund manager tests. When the auth pattern was causing timeouts it was refactored. The test suite was treated as a product in its own right, something to be maintained and improved, not just accumulated.

The multi-tenancy decision taught me the real cost of deferring foundational decisions. Proper data isolation at the organisation level required more upfront work. It was the right call. During a deliberate adversarial audit mid-build, two genuine cross-tenant data leaks were found and closed before a single customer touched the platform. That audit only happened because security was treated as a first-class concern from day one. I have seen what happens when that decision gets deferred. It was not a trade-off I was willing to make.

The AI scoring engine taught me about hypothesis validation. Assumptions were tested explicitly before committing to an architecture. A concurrency implementation had a bug that only surfaced under load. A prompt caching assumption turned out to be wrong because the minimum token threshold was higher than documented. The per-assessment cost projection was revised twice as real data replaced estimates. None of those surprises were catastrophic because the approach was to validate before scaling, not to build the full system and discover the problems at the end.

The hardest lesson was about scope. Scope creep does not announce itself. It arrives as helpfulness.

Every session had a moment where it would have been easy to fix something adjacent, tidy something nearby, improve something almost in view. The discipline of one commit per logical change sounds simple until you are tired and the temptation to bundle things together is real.

Building in a world full of shortcuts

There is a lot of noise right now about what AI can do. You can take an idea from zero to a live product in 48 hours. You can generate code, deploy it, and start charging for it before the week is out. That is genuinely remarkable.

But there is a question nobody seems to be asking loudly enough: built properly by whose standard?

I kept coming back to a specific test throughout this build. Not whether the product worked, but whether it would pass scrutiny from a CTO evaluating Nire as an acquisition. That asks whether the data model is sound, whether security is genuine or cosmetic, whether the test suite actually covers behaviour or just exists to show a number. We ran that audit more than once. Not as a one-off exercise but as a recurring discipline. Every time, findings went back into the product.

Most products being built at speed right now are being built to a demo standard, a revenue standard, or a good enough for now standard. Those are legitimate choices for certain goals. They were not the choice I made, because of who will use this platform. Fund managers making investment decisions. Founders sharing sensitive information about their business in the hope of getting funded. Data isolation, security, honest scoring that cannot be gamed. These were not features on a backlog. They were the terms on which the product was allowed to exist.

The opportunity AI gives us is not to ship faster and worry about quality later. It is to build properly, at a pace that was previously impossible, with standards that used to require a full engineering department to maintain.

What actually shipped in four weeks

It did not start as a build. It started as a question: is this the right thing to build, and am I solving the problem in the right way? The first versions were prototypes. Enough to validate the shape of the problem and figure out what actually mattered before committing to building it properly.

Then came two products on top of a proper foundation: three repositories, Supabase with row-level security from day one, a full auth chain, Stripe, Resend, the Anthropic API, GitHub Actions CI, Vercel.

The fund manager platform: portfolio dashboards, KPI tracking, runway visibility built to real VC conventions, investment rounds, audit logging, notifications. The thing I kept wishing existed, at a price point that makes sense for most funds.

The founder platform: eight dimensions of investability, a dual-layer scoring engine with a deterministic heuristic foundation that cannot be gamed and an AI layer handling the nuance a ruleset cannot, score reveal, PDF report generation, payment gate, and a consent-based connection into fund manager deal flow.

Over 1,100 unit tests. A full end-to-end suite. A marketing site, three blog articles, a pre-seed fundraising narrative.

Four weeks. Two products. One person.