An MVP to find out if the idea pays off before you spend the whole budget
Scoping
We separate what tests the hypothesis from what just makes the project more expensive.
Hypothesis and metric
We define what has to happen for the idea to count as validated.
Core flow
We design the path the user takes to the moment of value.
Lean interface
Enough screens to use the product, with no excess that delays launch.
Custom engineering
Front end, back end and integrations built to last beyond the test.
Login and billing
Accounts, plans and payments set up when the hypothesis involves revenue.
Instrumented metrics
Product events from day one, so the decision comes from data.
Handoff with documentation
Code, access and documentation so the team can carry on alone.
COMPARISON
The difference between an MVP that gives answers and a small product that proves nothing
We've built digital products for Wiz Benefícios, Pepper, Milhas Pix, Gogame and Cappta, and we run our own SaaS in production.
WHO IT'S FOR
Wama vs. building everything at once
Those who try to launch the full product in the first version find the mistake after the bill is already paid.
Wama
Building everything at once
First version live in weeks
Months before anyone outside uses it
Fixed scope, with what's left out in writing
A backlog that grows with every meeting
Metric defined before building
Launch with no success criteria
A codebase that survives the test
A prototype that has to be thrown away
Code and access handed over to you
Dependence on whoever built it
Scoping
We understand the problem, who pays for it and what question the first version needs to answer. This stage produces the scope and the list of what comes later.
Design
We map the core flow and design the screens it needs. You click through the prototype before a single line of code exists.
Build
Development in short cycles, with clickable versions for you to test along the way and correct course early.
Launch and readout
We launch, track real usage and read the metrics with you to decide whether to evolve, change direction or stop.
Strategy
Interface Design
Web Design & Software
Branding
Consulting
Design System
UI & AI
Motion
Businesses transformed
Framer™ projects
Years in business
A disruptive project needs design that breaks past the ordinary, and that is what we guarantee.
Henrique Sabino
Wama Founder
01.
How much does an MVP cost?
It depends on the size of the scope and the integrations. Most of the MVPs we build start above US$10,000, and what moves the price most is the number of screens, permission rules and connections to third-party systems.
02.
How long does it take to launch?
An MVP with an honest scope takes two to four months. When the deadline slips, it's almost always because the first version tried to solve three problems instead of one.
03.
What exactly is an MVP?
It's the smallest version of the product that can answer a business question with real users. It isn't an unfinished product or a throwaway prototype: it's software in production, with a deliberately narrow scope.
04.
Do I need to have everything figured out?
No. Plenty of people come to us with an idea and a spreadsheet. Part of our job is turning that into an executable scope, with what's in and what's out written down before we start.
05.
Can the MVP code be used later, or will it be thrown away?
It can be used. We build with the same discipline as a product that's going to grow, so the codebase carries on when the hypothesis is confirmed. A throwaway prototype is something else, and we tell you when that's the case.
06.
Can I validate before writing code?
In many cases you can, and it's cheaper. A page that explains the offer and collects interest already answers a lot. When that path works, we suggest it before selling you an MVP.
07.
How do I know if the MVP worked?
By the metric we agreed on before building. It could be sign-ups that activate, a completed task or a first payment. Without that number defined at the start, the launch becomes a feeling, not an answer.
08.
Do I own the code?
Yes. We hand over the repository, access and documentation at the end. Our goal is for your team to keep evolving the product without depending on Wama.
09.
Do you sign NDAs?
We do. It's standard practice on our product projects, and the agreement can be sent before the first technical conversation.
10.
And once the MVP validates the idea?
We keep evolving the product on a monthly retainer, deliver through hour packages, or hand off to your in-house team with documentation and a support period.