MVP build

Free consultation Projects

The first version of your product running in production - with sign-in, data, error handling and measurement of what the first users actually do. Not a deck for the board, but an address you can send people to.

We have worked with leading companies and startups

Challenges

Three moments when an MVP costs less than more planning

Not sure whether this is already the moment for an MVP or still one for an interactive design? Book a consultation - we will say plainly which of the two is worth buying first.

  • „The prototype is approved and there is nothing left to rewrite”

    A clickable version of the product has been through decision-makers and users, and the next step is not a new design but connecting data and accounts. Instead of starting over, we add to the existing code the layer the prototype never needed.

  • „The idea has a budget and a deadline but not a single user”

    A decision about a large rollout is about to be made on the basis of a document and estimates nobody has verified in real use. A version you can hand to twenty people settles in a few weeks the arguments that have been running through meetings for a quarter.

  • „An internal tool has outgrown the spreadsheet or the no-code platform”

    A solution assembled in a hurry now handles other people's data, several roles and processes that somebody's daily work depends on. That is the moment to move it onto your own code - before a platform limit blocks a feature that cannot be postponed.

Who it is for

Who we build a first version for

  • Founders before funding conversations or just after them

    The deck defended the idea, but the follow-up questions are already about whether anyone is using it and how they behave. We build a version you can hand to first users and show in a conversation as a working product rather than a set of slides about a future one.

  • Product teams moving into a new area next to the main product

    A new module or a separate product line has to be tested, but pulling it into the main repository would block the roadmap for a quarter. We stand it up alongside, on its own deployment, and only a confirmed solution comes back to the discussion about folding it into the core product.

  • Companies whose internal tool grew out of a stopgap

    A spreadsheet, a form and a few automations now carry a process a whole department depends on, and every change requires one specific person. We move that process onto a proper application with accounts and a change history, starting from the action performed most often.

  • IT departments and software houses with no spare hands for another product

    The skills are in-house, but the whole team is committed to current clients and a new idea has been queuing for months. We run the build alongside your team, in your conventions and your repository, so taking the product over after launch does not mean learning somebody else's code.

Four printed interface layouts on a desk: a dashboard, a phone screen, a form and a table, with one block circled in marker

Our difference

What makes our approach different

  • We finish the prototype instead of rewriting it

    In the usual arrangement the design is made in a graphics tool and then a second team reproduces it in code - and that reproduction is a separate, full stage. Our interactive design is code from the very beginning, so the MVP starts by adding a backend to something that already works and has been approved.

  • The speed comes from a removed handover, not from an off-the-shelf library

    The common promise of a faster MVP rests on assembling screens from ready-made component kits - the pace goes up, but the interface ends up looking like a hundred other products built from the same kit. We shorten the road where time is actually lost, at the seam between design and implementation, and the look stays yours.

  • We name the ceiling before the first line of code

    The most expensive MVP is the one that worked, won users and six months later turned out to be impossible to extend without rewriting everything. So before we choose a stack, we write down at what number of users, which integration and which data requirement the current solution stops being enough.

  • The list of rejected features is part of the delivery

    An MVP scope is cut once and then defended for a dozen weeks, usually in front of people who were not in that room. A recorded decision with its reasoning closes that argument in a minute and means a deferred feature returns at a planned moment, not in the middle of work on the main path.

Process

6–14 weeks from cutting the scope to the first accounts in production

  1. Week 1

    Cutting the scope

    We establish which single decision this version has to settle and which path the user takes to reach it. Everything that does not touch that path lands on the deferred list - together with the condition on which it returns to the conversation.

  2. Week 1–2

    The technical ceiling and the stack

    Before the first line exists, we name the limits of the chosen solution - the number of users, the integrations, the requirements around personal data. The stack is chosen for the version after the MVP, not for the MVP itself, because the MVP alone can be delivered on almost anything.

  3. Week 2–6

    The main path in code

    We build the journey from entry to the moment the user gets value, and push it to staging straight away. Each following week closes with a working release you can click through, so progress is reviewed in the product rather than on a task list.

  4. Week 4–10

    Accounts, data and integrations

    Sign-up, sign-in, roles and permissions, persistent data storage and connections to the systems without which the product makes no sense - payments, email, a CRM or an API on your side. This is also where we settle which data we genuinely need to collect and which we are better off not holding.

  5. Week 8–14

    Hard edges and going live

    Error states, empty views, behaviour on a dropped connection, keyboard and screen-reader operation, performance on a weaker phone. Then the domain, backups, monitoring and letting the first accounts in - usually in batches rather than all at once.

Deliverables

Three things on delivery. The product, the scope decision and the first measurement

  • An MVP scope - including the list of what stays out

    Features split into the ones without which the main path cannot be completed, and the ones that wait for the version after validation. The rejected list is recorded together with the reason for rejection, so six months later nobody has to reconstruct that conversation.

  • A product in production - accounts, data, deployment

    A working application on your own domain - sign-up and sign-in, user roles, persistent data, error and empty states, a mobile version. Plus a staging environment alongside production and releases shipped from the repository rather than by hand.

  • Measurement of the first users and a backlog for the next version

    Analytics events wired into the steps of the path that actually settle something, plus a channel for collecting feedback from the first accounts. After a month you get a summary of where people drop off and a backlog arranged around those places.

Toolkit

What we use

The things we do not skip in a first version, because adding them later costs many times more than doing them straight away - accessibility, data protection and repeatable deployments.

A workbench from above: two printed interface layouts, a magnifier enlarging one block, a steel ruler and a greyscale step wedge running from white to black, with one line underlined in orange marker
  • TypeScript on the frontend and the backend
  • Authentication, roles and permissions from the first release
  • WCAG 2.2 AA on the main path
  • A staging environment alongside production
  • Releases from the repository, with a way back
  • GDPR - data minimisation and explicit consent

Next step

Let us talk about your project

Tell us what you have to do. We will come back with scope and a quote.

Free consultation Projects

Selected work

Projects from the products we build from a first version

A selection from the product types we most often stand up a first working version for - web applications, panels and internal tools. Some of these builds are under confidentiality, so we show them during a consultation.

Projects

Outcomes

What you get, by when, and how you can verify it

  • 6–14 weeks

    From cutting the scope to a version real users work with - six weeks for a single path built on an existing interactive design

  • 1 codebase

    The prototype and the production version are the same project in your repository - there is no stage of rewriting mockups into code

  • WCAG 2.2 AA

    The public W3C accessibility standard we check the main path against before the first accounts are let onto it

  • 30 days

    The window after launch in which we fix issues coming out of real use and close the first measurement of user behaviour

The turnaround and the scope come from the schedule described above on this page, and WCAG 2.2 AA is a public W3C standard. We do not quote averaged funding rounds or user numbers won by clients - that data belongs to them, and we show it by name during a consultation, with their consent.

Client voices

What our clients say

  • „Working with the Wzór team was a genuinely great experience! They always answered our questions quickly and were flexible about our comments. They have no shortage of creative ideas and are at the same time thoroughly reliable and on time. The end result fully met our expectations; we recommend them to anyone looking for professionals who care.”
    Maja Wieloch-Silecka Operations Director, Bosfor Group
  • „Our clients expect us to act fast and effectively across a very wide scope - from building a brand, through a website with a store, to running an effective sales campaign. Not an easy task, but doable when you have a tight-knit team and partners who take on challenges on the fly. For us, quality, accountability and commitment are key, and working with UX Agency Wzór gives us that 100%.”
    Piotr Alberski Chief Operating Officer, Agencja XO Media
  • „Our cooperation with UX Agency Wzór started with our own website. We really liked the way they work, so we decided to subcontract projects for our clients to them on a White Label basis. We loved their workflow, the way they hand projects over to our team, their documentation and their work on the design system. Now we can take on bigger risks.”
    Mateusz Swół Chief Operating Officer, Sellace

Time and scope

How long the build takes and what drives the quote

6–14 weeks

Six weeks is one main path built on a finished, approved interactive design, with a single user role and without elaborate integrations. Fourteen weeks and beyond is a product with several roles, payments and data exchange with systems on your side - in that case we split the work into releases, so the first users get something in their hands earlier.

  • The number of paths and user roles in the first version

  • The starting point - a finished interactive design or a start from scratch

  • The scope of integrations with systems, payments and external sign-in

  • Requirements around personal data and obligations arising from your industry

  • Whether your team takes the product over after launch or we keep running it

FAQ

Questions that come up most often

How much does an MVP build cost?

We quote each build individually, because two MVPs with the same name can differ several times over in scope. The price is driven by the number of paths and user roles in the first version, the starting point (an existing interactive design or a start from scratch), the scope of integrations - payments, external sign-in, data exchange with your systems - the requirements around personal data, and whether your team takes the product over after launch or we keep running it. You get a concrete proposal with the scope broken down within 48 hours of the brief.

How does an MVP build differ from an interactive design?

An interactive design is a working, clickable product without a server layer - excellent for decisions and conversations, but the data disappears on refresh and nobody can create an account in it. An MVP adds what the prototype never needed - sign-in, persistent data storage, permissions, integrations and a production deployment. If you are ahead of a first version, it is usually cheaper to start with an interactive design and then finish that, because the MVP does not begin with a rewrite.

Can an MVP be built on no-code?

Sometimes yes, and then we propose it ourselves - if the product has one role, a simple data model and mainly serves to test interest, a no-code build can be faster and cheaper. The ceiling appears with multiple roles, unusual permissions, larger data volumes and integrations on your side. That is why we name that ceiling before choosing the tool - moving from a platform onto your own code after the fact costs more than building the latter straight away.

We already have a design in Figma. What changes then?

We work with what exists - mockups shorten the stage of settling paths and visual direction. What changes is that a graphic design has to be translated into code, so the saving that comes from finishing an existing prototype disappears. We start by reviewing the mockups for the states they usually lack - errors, empty lists, long content, the mobile version and keyboard operation. We fill those gaps in code rather than sending the design back to Figma.

Who owns the repository and what happens after launch?

From day one the code sits in a repository that belongs to you, together with the deployment configuration and documentation for running the project on a new machine. For thirty days after launch we fix issues coming out of real use and close the first measurement of user behaviour. After that we either hand the product over to your team along with the backlog for the next version, or keep running it - a decision that can be made after launch rather than before it.

What if the MVP shows the idea does not work?

That is the result a first version is built for, and the cheapest moment to learn it. It is rarely binary - more often it turns out that people come in but drop off at one specific step, or use the product differently than the scope assumed. That is why we wire measurement into the points of the path that settle something. At the end you get a summary of where people drop off and a recommendation - fix the path, change the audience, or stop before a larger rollout.

Related services

Related services

Book a free consultation with an expert to discuss your project and get answers to your questions.

- Patryk Korycki, CEO

Schedule a meeting
Book a free consultation