Why We Build the Account Foundation Before the Headline Feature

Founders understandably want to start with the feature that makes their product special: the matching, the listings, the booking. On two marketplace apps, we deliberately started somewhere less exciting. We built the account and authentication foundation to production standards first, then built the headline feature on top of it.

One was the foundation layer for an equipment marketplace app. The other was an in-house sports-matchmaking concept connecting players, trainers and field owners. Both were built with React Native (Expo) on mobile and NestJS on the backend.

Why accounts first

Nearly everything in a marketplace depends on who the user is: what they can list, what they can see, who they can message and how they pay. If the account model is wrong, every feature built on it inherits the problem.

Accounts are also the hardest part to change later. Once real people have signed up, changing how identity, sessions or roles work means migrating live user data and asking users to log in again or re-verify. Getting it right while there are no users is far cheaper.

What "production-grade" meant in practice

Complete account flows

On the matchmaking app, that meant secure signup, email verification and password reset from the first release. These flows are easy to postpone and painful to add under pressure when the first user forgets a password.

On the equipment marketplace, transactional email was handled through a dedicated email provider integration rather than the server's default mail setup, because verification and reset emails that land in spam are the same as no emails at all.

Sessions that behave on mobile

Mobile apps need to keep people signed in without storing secrets carelessly. The equipment marketplace used auth-state-driven navigation (the app decides which screens to show from the current authentication state) and secure on-device token storage. The matchmaking app used JWT-based session persistence on mobile.

Every user type designed in

The matchmaking concept had three sides: players, trainers and field owners. We designed that three-sided user model in from the start, even though the core matching feature was still to come. Adding a second or third type of user to a model built for one is one of the most common and expensive MVP rewrites.

The parts nobody sees until something breaks

Two further investments cost little at the start:

• Global exception handling and request tracing. On the equipment marketplace, every request can be traced and errors are handled consistently. When a user reports a problem, there is a trail to follow instead of a guess.
• A documented API. Both backends were documented with Swagger as they were built. The mobile app and the backend work from the same description, which removes a whole category of integration misunderstandings.

Doesn't this slow the MVP down?

A little, at the start. But the alternative is not "faster". It is building on a foundation you will have to replace while users are on it. An MVP should be small in scope, not low in quality where quality is hard to add later. Accounts, security and observability are those places.

What we keep small instead is the feature set: one core workflow, done properly, on a foundation that will not need rebuilding. The infrastructure choice deserves the same care; see a serverless backend for a two-sided marketplace.

An account-foundation checklist for any MVP

• Signup, email verification and password reset work before launch.
• Transactional email goes through a proper provider.
• Tokens are stored securely on the device.
• All planned user types exist in the data model, even if some are hidden.
• Errors are handled centrally and requests can be traced.
• The API is documented as it is built.

The anonymised write-ups are for the equipment marketplace foundation and the sports-matchmaking app. If you are planning a first release, our MVP service starts with exactly this kind of scoping. For another way we reduce early risk, see proof of concept first.