What to Prepare Before an MVP Kickoff
By CodexierPublished 6 min read
The first weeks of an MVP project are often lost to things that have nothing to do with code: nobody can decide, the domain belongs to a former co-founder, the Apple developer account is still under review, the logo exists only as a screenshot. Each one blocks a specific task, and together they push the launch by weeks. This guide is the preparation list we send clients before a kickoff, so the build starts on day one.
Decision maker and availability
An MVP build produces a decision a day: which of two flows, whether a field is required, what happens on an error. If those decisions wait for a weekly meeting, the build waits with them. Appoint one person with the authority to answer within a day, and agree how they will be reached. If that person is the founder who also runs sales, block the time in the calendar now, because the build will not survive on the gaps between customer calls.
Users, problem and success metric
The developers need to understand the user well enough to make the small decisions without asking. That does not require a hundred-page specification; it requires a clear paragraph and one number. Write down who the first users are, the problem they have today, how they solve it now, and what they will do in the product in the first ten minutes. Then choose the metric that says the MVP works.
| Item | What good looks like | What blocks the build |
|---|---|---|
| First users | A named segment you can reach: ten specific companies or people | Everyone in Sweden who has a car |
| Problem today | The workaround they use now, with its cost in time or money | A market-size statement |
| Core flow | The one path from sign-up to value, in five to eight steps | A list of forty features with equal priority |
| Success metric | One number, measurable in the product, with a target for month one | Growth, engagement or traction without a definition |
Accounts: domain, cloud and stores
Accounts should be created by your company, in your company's name, before the kickoff, with the developers added as collaborators. This is the single most common cause of a delayed launch and the easiest to prevent. Some of these take days to approve, and a store review clock cannot be shortened by anyone.
- Domain registered to your company, with access to the DNS. Check who actually owns it if it was bought years ago.
- Cloud or hosting account (for example Vercel, Supabase, AWS) with billing set up on a company card, and a region decision for data residency.
- Apple Developer Program and Google Play Console, applied for now if there is a mobile app; both verify the organisation and can take time.
- A GitHub or GitLab organisation owned by you, so the code lives in your account from the first commit.
- Transactional email service, analytics, error tracking and a payment provider if the MVP charges money, each in the company's name.
- A shared password manager vault for the project, instead of credentials in chat messages.
Brand assets and content
Screens are built around content, and placeholder text hides problems: a real company name is longer than Lorem, a real error message needs a real tone. You do not need a finished identity, but the developers need the pieces that exist, in usable formats.
Logo and colours
Logo as SVG, primary and secondary colours as hex values, and the font if you have one. A screenshot of the logo is not usable.
Words for the first screens
The product name, the one-line description, the names of the main objects (is it a project, a case, a booking?) and the language: Swedish, English or both from the start.
Sample data
Ten realistic records of whatever the product manages, anonymised. Real-shaped data reveals the fields, formats and edge cases the specification missed.
Legal basics: terms and privacy
An MVP with real users is a product with legal obligations from the first sign-up. None of this needs a law firm for a first version, but it needs decisions, because the developers will build the sign-up, the consent and the data deletion according to what you decide.
- Terms of service and a privacy notice, drafted from a template and reviewed for your case, published before the first external user.
- Where personal data is stored: an EU region is the simple answer for a Swedish product, and it must be chosen before the database is created.
- Which data you actually need at sign-up; every extra field is a GDPR question and a conversion drop.
- How a user deletes their account and data, because that must exist at launch, not later.
- The company details on the site and in emails: legal name, organisation number, contact address.
- If B2B: a data processing agreement template your customers can sign, since their procurement will ask.
When you do not need this list: if you are validating an idea with a landing page and a waiting list, prepare the domain, the words and the privacy notice and skip the rest until something is built. The full list is for a build with real users and real data. If you are not sure the scope is right yet, our MVP planning blueprint turns the paragraph and the metric above into an architecture and a build plan before anyone commits to development; it is priced on the pricing page, or book a call and we will tell you which items on this list you are still missing.
Frequently asked questions
How much of the specification should be ready before kickoff?
The paragraph about users and problem, the core flow and the success metric. A detailed specification of every screen is not needed and often harmful, because it fixes decisions that should be made with a prototype in hand. The kickoff is where the detail gets produced.
Should the developers create the accounts for us?
They can help, but the accounts must be owned by your company and paid for with your card. Accounts created under a supplier's email are a recurring source of lost domains and locked stores when the relationship ends.
What if we do not have a logo or a name yet?
Pick a working name and a single colour and proceed. Renaming a product before launch is cheap; waiting for a finished identity is expensive. The brand can be applied in the last week of the build.
Do we need terms and a privacy notice for a closed beta?
Yes, at least a short version. Beta users are still users whose data you process, and a clear notice from the start is easier than retrofitting consent later. A template reviewed for your data flows is enough for a beta.
Kickoff coming up and not sure you are ready?
Fifteen minutes: we go through this list with you, mark what is missing and tell you what would actually delay the build. Free, and useful whoever ends up building it.
Book a free 15-minute call