I posted about building Nire yesterday. Here is the full story of what the last month actually looked like.

A few people asked for more detail after my last post. This is the honest account of what building Nire actually took.

The reason it exists

I named the company after my daughter. Nire is Erin spelled backwards. She is six. The pink in the brand is her favourite colour.

I did not name it after her because it was a nice story to tell investors. I named it because I wanted to build something that outlasts me. That felt like the right kind of pressure to build under.

What I had never done before

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. 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. I used Claude Code as my execution layer throughout. Not a single line of code written directly. Every architectural and product decision was mine.

What the problem actually is

The problem came from years of strategy work sitting across the table from PE firms and VC funds. Fund managers trying to understand how their investments were performing, stuck between spreadsheets and enterprise platforms most funds cannot justify the cost of. Founders walking into those same rooms completely unprepared, no honest self-assessment, no benchmark, no idea how they would be evaluated.

Two broken halves of the same system.

What 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 the right way? The first versions were prototypes. Only once that felt validated did I move into a proper build.

Three repos. Next.js app, static marketing site, git submodule for the assessment framework. Supabase with row-level security from day one, Stripe, Resend, Anthropic API, GitHub Actions CI, Vercel.

Two complete products on top of that foundation.

The fund manager platform: portfolio dashboards, KPI tracking, runway monitoring built to real VC conventions, investment rounds with MOIC calculations, audit logging, notifications. Manual input and CSV upload at soft launch with API integrations into Xero and QuickBooks coming very soon after.

The founder platform: eight-dimension investability assessment, dual-layer scoring engine with a deterministic heuristic foundation that cannot be gamed and an AI layer on top via the Anthropic API, hard $1 per-assessment budget ceiling, score-once caching, async interstitial so users never wait on a slow API call, PDF report generation, Stripe payment gate.

Proper multi-tenancy with isolation at the organisation level. During a deliberate adversarial audit mid-build, two cross-tenant data leaks were found and closed before a single customer touched the platform.

Over 1,100 Jest tests written test-first throughout. Full Playwright E2E suite, refactored twice, partitioned by product surface so a change to the founder flow does not run fund manager tests.

Marketing site, three blog articles, legal pages, Search Console, pre-seed fundraising narrative.

Four weeks. Two products. One person.

What I actually learned

The most valuable thing I built before any product code was a document called CLAUDE.md. It started as rules for the AI coding tool. It became the institutional memory of the entire build. Every lesson learned the hard way was encoded as a rule so it could never be forgotten mid-session.

Diagnose before acting, every single time. No implementation until a written diagnosis is approved. Every time that rule was followed, problems were caught early. Every time it was skipped, something went wrong.

Tests first, confirmed failing. The only honest way to know your tests actually test anything.

Never set thresholds from a single observation. Calibration across multiple runs. Single observations feel like certainty. They are not.

Scope creep does not announce itself. It arrives as helpfulness.

The thing that keeps coming back to me

Everyone is shipping AI products in 48 hours right now. But built properly by whose standard?

I kept asking throughout: would this 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. Every time, findings went back into the product.

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.

Where it is now

Soft launch to a small group of trusted founders is the next step. Full public launch follows shortly after.

Full write-up on the blog if you want to go even deeper: nirehq.com/blog/building-nire-one-month

Happy to answer questions on the technical architecture, the scoring methodology, the AI integration, or the non-technical founder experience of building this way.