Weeks 1–3
Discovery
We find out who this is for, what they do today instead, and what has to be true for the product to be worth building at all.
- Interviews with real users
- Competitive and pricing teardown
- A scope we would sign our name to
All solutions
Product engineering
The product team you have not hired yet.
Discovery, design, engineering, and the cadence to keep shipping after launch, in one squad that owns the outcome instead of the ticket. We work the way an in-house team should work, and we hand it over that way too.
- 10–14 weeks
- from kickoff to an MVP that real users can pay for
- Every 2 weeks
- a release you can use, not a status report you have to read
- One squad
- the roles your project actually needs, and nobody swapped out halfway through
- ES · EN
- a senior team in your time zone, in both languages
The work
Four phases. You can start at any of them.
Most clients come to us mid-way, with a prototype that stalled or a v1 that cannot take the load. We pick up where you are rather than restarting for the sake of it.
Weeks 3–6
Product design
Flows, screens, and a clickable prototype your team can put in front of users before a line of production code exists.
- Clickable prototype
- Design system, not one-off screens
- Usability tested before it is built
Weeks 6–16
MVP build
The smallest version that solves the problem end to end and can take real users, real money, and real load, built to be extended rather than thrown away.
- Two-week releases from the first one
- Tests, CI, and monitoring from day one
- Auth, billing, and admin included
- Analytics wired before launch, not after
Weeks 16+
Scale
What happens after product-market fit: performance under load, the second and third feature line, and a codebase your own hires can walk into.
- Performance and cost work
- Hardening, on-call, and incident runbooks
- Hiring plan and onboarding for your team
- Handover that does not depend on us
The weeks on each phase are a reference from past projects.
Signals
You probably need a product team when…
If two of these are true, the next hire is not the bottleneck. The way the work is organised is.
- 01
You have a prototype that impresses in demos and falls over with twenty users.
- 02
Your roadmap is a list of features nobody has traced back to a user problem.
- 03
Every release is an event that needs a weekend and three people on standby.
- 04
The agency that built v1 is gone, and nobody left can explain the code.
- 05
You are hiring your first engineers and have nothing for them to walk into.
- 06
Design, backend, and frontend are three vendors who have never met.
The squad
Who actually shows up.
These are the roles we work with. How a squad is put together depends on the project, so we size it with you rather than selling you a fixed shape. What does not change is that the people in the kickoff are the people doing the work, with no account manager relaying messages to people you never meet.
Product lead
Owns: Scope and prioritiesOwns scope and the tradeoffs that come with it. Runs discovery, writes down what we are building and why, and is the person you call when priorities change.
Product designer
Owns: Interface and designFlows, interface, and the design system. Sits in user sessions rather than reading a summary of them, and stays on through build so decisions do not get lost in handoff.
Engineers
Owns: Frontend and backendFrontend, backend, and infrastructure, in whatever mix the project calls for. Senior enough to push back on a requirement that will cost you later.
Technical lead
Owns: Architecture and standardsArchitecture, code review, and the standards that keep the codebase hireable. The one who says no to the shortcut that saves a week and costs a quarter.
Cadence
What a two-week cycle looks like.
Same rhythm every cycle, from the first week to the last. It is deliberately boring, because predictability is what lets you plan anything around us.
01When: Day 1
Plan
We agree on what ships in this cycle and, more usefully, what does not. Scope is cut here, in the open, not quietly on day nine.
Ends withA committed scope for two weeks
02When: Days 2–8
Build
Design and engineering work in parallel against the same goal. Everything merges behind flags into a staging environment you can open any morning.
Ends withWorking software on staging, daily
03When: Day 9
Test
Automated suites, a manual pass on the flows that matter, and accessibility checks. Bugs found here are fixed before the demo, not logged for later.
Ends withA release candidate that passed
04When: Day 10
Demo
Forty-five minutes where we use the software in front of you. No slides. You click it yourself and tell us what is wrong while changing it is still cheap.
Ends withA version in your hands
05When: Day 10
Decide
We ship to production, look at what the last release actually changed in the numbers, and choose the next cycle from that rather than from the original plan.
Ends withA release in production and a decision
What you get
Everything, not just the running app.
A product you cannot maintain without us is not finished. These come with the engagement, not as an upsell at the end of it.
A design system
Components, tokens, and states in Figma and in code, so the tenth screen takes hours instead of days and looks like the first nine.
Code with tests
Coverage where it earns its keep: business rules, money, and permissions. Enough that a new engineer can change something without holding their breath.
A deploy pipeline
Push to deploy, with previews on every pull request and a rollback that takes one command and no heroics.
Analytics that answer
Events defined around the decisions you will actually make, instrumented before launch, so week one tells you something.
Documentation
Architecture, decisions and why they were made, environment setup, and runbooks for the things that break at 2am.
A real handover
Repositories, accounts, and domains in your name, plus the sessions to walk your team or your new hires through all of it.
Stack
What we build it with.
Boring, well-documented technology your next hire already knows. We pick for the team that inherits this, not for our own curiosity.
- Design
- Figma
- Design tokens
- Prototyping
- User testing
- Frontend
- Next.js
- React
- TypeScript
- Tailwind
- Backend
- Node
- Python
- PostgreSQL
- REST
- tRPC
- Mobile
- React Native
- Swift
- Expo
- Infrastructure
- Vercel
- AWS
- Docker
- GitHub Actions
- Quality
- Playwright
- Vitest
- Sentry
- PostHog
How we engage
Three ways to start.
The difference is who sets the priorities and how far ahead they are fixed. All three have the same people and the same cadence.
01
Fixed-scope MVP
We agree the scope after discovery, quote it once, and deliver it. Changes are priced openly as we go, never absorbed silently and billed at the end.
Best for
Founders and new product lines that need a launch date they can plan a company around.
Includes
- Discovery and a fixed quote
- Design and build to launch
- 30 days of post-launch support
- Full handover
02
Dedicated squad
A standing team on a monthly retainer, with the backlog set by you each cycle. The usual choice once a product has users and the roadmap outlives any one scope.
Best for
Companies with a live product and more roadmap than internal capacity.
Includes
- A named, stable team
- Two-week releases
- Priorities you set each cycle
- Monthly reporting on outcomes
03
Embedded with your team
Our engineers and designers work inside your existing team, in your repositories and your rituals, usually to raise the floor rather than add headcount.
Best for
In-house teams that need senior depth or a practice they do not have yet.
Includes
- Work inside your process
- Code review and mentoring
- Standards and tooling upgrades
- A defined exit, agreed up front
Proof
See what we have built.
Products we run ourselves and systems we built for clients, with the decisions behind each one.
Questions
What founders and product leads ask us.
What does an MVP cost?
Most land between a well-paid senior hire for a year and twice that, which is the honest comparison since that is the alternative. We quote after discovery, fixed, and discovery is quoted separately so you can stop there with a scope and an architecture you own.
Who owns the code and the accounts?
You do, from the first commit. Repositories, cloud accounts, and domains are in your company's name, intellectual property transfers in the contract rather than as a favour at the end, and nothing we write is reused elsewhere.
We already have engineers. Does this still work?
Yes, and it is a common way to start. We either take a product line your team cannot get to, or work inside your repositories with your process. What does not work is two teams building the same thing without one person deciding priorities.
Can you work from designs we already have?
Yes. We will review them first and tell you where they will cause trouble in build, but we do not insist on redrawing work you have already paid for. If there are no designs at all, design is part of the engagement.
What happens after launch?
Whatever you choose. Some clients keep the squad and keep shipping, some move to a smaller support arrangement, and some take it in-house, which is why the handover and the documentation exist. We do not build in a dependency to make leaving expensive.
We only have an idea. Is it too early?
Not for discovery, which is three weeks and ends with a scope, an architecture, and a number. It is too early for a build if nobody has spoken to a potential user yet, and in that case we will say so before taking the project.
Tell us what you are trying to put in front of users.
Send us a paragraph about the product and where it is stuck. We will come back with how we would approach it, what the first phase would take, and the parts we think are wrong.
The first conversation is free. If we are not the right fit, we will say so.
info@upsky.org