Building GritGateway from Idea to MVP in 3 Months

Edouard came to me in November 2025 with a concept, not a spec. He had a clear sense of the problem he wanted to solve and a rough mental model of the user, but no technical foundation, no stack decision, and no one to tell him whether his assumptions would survive contact with real infrastructure. That is the exact moment I find most interesting to enter a project. The brief was simple: build GritGateway from scratch, get to a working MVP, and do not waste the first six months on things that do not matter.

The first thing we did was not write code

Before any repository existed, we spent three weeks in what I call a discovery sprint. I asked Edouard to walk me through the user journey he imagined, step by step, out loud. I took notes and pushed back on every assumption that would require a non-trivial technical decision later. What data does the platform own? What does it read from external sources? Where does money move, if anywhere? What happens when a user returns after thirty days of inactivity?

This is not a formality. Every hour spent here saved roughly four hours in rework later. By the end of those three weeks, I had a clear enough picture to make the first real architectural call: the product needed a clean separation between its public-facing layer and its core data model, because the two would evolve at very different speeds. That decision shaped every sprint that followed.

How I structured the technical architecture

I chose a modern full-stack approach with a clear API boundary. The frontend is a React-based application with a strong emphasis on component consistency, because a fragmented UI at the MVP stage compounds into a maintenance problem very quickly. The backend exposes a typed API layer, which means Edouard's team can extend the product without needing to reverse-engineer my intentions. I documented the data model before writing a single migration, not after.

For the development workflow itself, I integrated AI-native tooling from the start. By late 2025, using tools like Cursor alongside Claude for code generation and review had become a serious productivity multiplier, not a novelty. Industry practitioners were reporting 30-plus percent reductions in scaffolding and integration timelines, and my experience on GritGateway confirmed that range. Boilerplate that would have taken a day took a morning. That time went into the parts that actually required judgement, the auth flow, the data access patterns, the edge cases in the user lifecycle.

Authentication and session management got more attention than they usually do at the MVP stage. That is a deliberate choice. Retrofitting a secure auth model onto a product that already has users is painful and risky. Getting it right early costs almost nothing by comparison.

Where the real friction was

The hardest part of this engagement was not technical. It was the gap between what Edouard wanted the product to be and what the MVP needed to be. He had genuine product instincts, which is an asset, but those instincts kept generating scope. My job, as much as building the thing, was to hold the line on what goes into version one.

We had one specific disagreement about a feature that would have required a third-party integration with meaningful compliance implications. I recommended deferring it. Edouard pushed back, reasonably, because he saw it as central to the value proposition. We resolved it by building a lightweight placeholder that signals the feature to users without activating the integration. That placeholder became a useful signal: it told us, before we built anything expensive, how many users actually cared about that feature. The answer informed the roadmap.

This is the kind of call that does not appear in a technical spec. It sits at the intersection of product thinking and engineering judgment, and it is one of the reasons I think of this work as closer to a Fractional CTO engagement than a pure build contract.

What the MVP actually shipped with

By mid-2026, GritGateway was live at gritgateway.com. The shipped product included:

• —User authentication and profile management, built to be extensible
• —The core platform flow Edouard had described in November, now validated against real users
• —An admin layer that lets the team manage content and user data without touching the codebase
• —A component structure that makes adding new screens fast and consistent
• —Instrumentation, so the team can see what users actually do, not what they say they do

Nothing on that list is glamorous. All of it is necessary. An MVP that ships without instrumentation is an MVP that cannot learn.

What I learned from this engagement

Building a product for a founder who is deeply invested in the idea is different from building internal tooling for a corporate client. The emotional stakes are higher. The feedback loops are tighter. And the founder's energy, when it is channelled well, is a genuine asset to the build.

Edouard's willingness to engage seriously with the architectural reasoning, rather than just reviewing screens, made the product better. We disagreed on scope several times. We always resolved it with evidence or logic, not seniority. That is the dynamic I try to establish early on every engagement.

I have built across very different contexts, from the Workbud shift management platform to the Financial Services Platform that required strict security standards, and the pattern that holds across all of them is this: the technical decisions that matter most are made in the first three weeks, when most people are still writing decks. Getting those decisions right is what makes the rest of the build tractable.

If you are at the stage Edouard was at in November 2025, the most useful thing you can do right now is have a direct conversation about your assumptions before they become your architecture. Start that conversation here.