Keep.
The useful screens, good ideas, working logic, and decisions you've already made. We start by understanding what deserves to stay.
Prototype to Production
Built it with AI?
Let's get it
to production.
Keep what works. Fix what doesn't. Get a reviewed, fixed-scope plan before anyone writes code.
Free review. Your code stays yours. You approve every next step.
Your next chapter
A path to the first real release.
01 / The thing you've builtSTART HERE
Real workflowsAccess & permissionsPersistent dataDeployment & tests
02 / The work we agree onFIXED SCOPE
Ready for the next step.Agreed tests. Your code. A clear handover.
Illustrative release pathREVIEW → SCOPE → BUILD
Wherever you started
LovableBoltReplitv0ChatGPTYour own stack
01 / The last mile
The idea is real.
So are the loose ends.
You've made something worth finishing. Now the login, data, payments, and release process need to hold up beyond the demo. Pick what sounds familiar.
WorkflowsExample scope / 01
The happy path is only the beginning.
The demo works when you click everything in the right order. Real people go back, skip fields, refresh, and try again.
1Start
2Validate
3Save
4Confirm
What we'd work on
Trace the important journey from first click to saved result. Repair the broken states, show useful errors, and make retries behave.
What “done” could look like
A customer submits a request, refreshes, and sees it exactly once. Missing information gets a useful message, not a dead end.
AccessExample scope / 02
A login screen is the start of access control.
People can sign in, but roles, password recovery, and who can see whose records still need attention.
1Sign in
2Check role
3Authorize
4Open record
What we'd work on
Review the agreed roles and protected actions. Enforce access where the data lives, and finish the account flows people need.
What “done” could look like
A customer can open their own record. Another customer's record stays inaccessible, including through a direct request.
DataExample scope / 03
Saved should still mean saved tomorrow.
The interface looks complete, but changes disappear on refresh, records duplicate, or the app still relies on sample data.
1Edit
2Validate
3Persist
4Reload
What we'd work on
Connect the interface to persistent data, validate what gets written, and agree how existing records should move with the app.
What “done” could look like
An update survives a refresh and a new session. Invalid input is rejected without damaging the existing record.
PaymentsExample scope / 04
Checkout has to work after the checkout screen.
The payment button works in a demo. Failed payments, repeated notifications, cancellations, and account access are still loose ends.
1Checkout
2Payment event
3Reconcile
4Fulfill
What we'd work on
Connect the agreed payment events to the right product behavior. Handle retries and failures without duplicate orders or incorrect access.
What “done” could look like
A successful test payment creates one order. A repeated event doesn't create another, and a failed payment doesn't grant access.
DeploymentExample scope / 05
Working locally is one stop before live.
It runs in the builder, but the production build fails, configuration is missing, or no one knows how to undo a bad release.
1Build
2Configure
3Deploy
4Verify
What we'd work on
Review the build and hosting setup, separate sensitive configuration, and document the agreed deployment and rollback steps.
What “done” could look like
The pinned version builds in the target environment. The named workflows pass there, and the rollback procedure is documented.
ReadinessExample scope / 06
Turn “almost ready” into specific decisions.
There's a lot of working software, a growing list of questions, and no clear way to decide what belongs in the first release.
1Name users
2Choose scope
3Define tests
4Decide
What we'd work on
Start with the people using it and the few things they must be able to do. Separate launch requirements from later improvements.
What “done” could look like
Each agreed launch workflow has an owner, a visible pass condition, and a clear place in the scope. Everything else is explicitly deferred.
These are examples of possible build work. Your review determines what's relevant, and your approved scope defines what we deliver.
02 / Respect the head start
You shouldn't have to
start over to move forward.
Repair.
The missing connections and unreliable behavior between a convincing prototype and a product people can actually use.
Rebuild.
Only where the tradeoff makes sense. If replacing part of the app is the better route, we'll explain why before you commit.
03 / Define the finish line
“Make it work”
isn't a scope.
This is.
Before a build starts, you should know exactly what you're buying and how we'll know it's finished.
We turn the agreed work into named workflows, visible pass conditions, and a fixed price. Changes to that agreement are decisions we make with you.
See how we get there
Your build agreement
A finish line you can point to.
- 01The exact starting point
A frozen commit or archive hash, so we're all reviewing the same code.
- 02The workflows we're finishing
Who does what, what needs to happen, and the agreed acceptance tests.
- 03The price and boundaries
Fixed scope, exclusions, and separately itemized third-party and recurring costs.
- 04The handover
Your agreed code, deployment notes, ownership terms, and correction period.
04 / A clear next step
First, a decision.
Then, a price.
Start small. Find out whether there's a sensible path forward. You'll agree to any paid work separately, with the deliverable and fee in front of you.
01 / Start here
Freefit check
Is this a project we can move forward?
A static look at your goal, known issues, key workflows, and a frozen code reference. Up to 20 minutes of review, with one clarification round.
- A clear fit verdict and recommended next step
- No dependency installs or code execution
- No commitment to paid work
02 / If we need to investigate
$300up to 2 hours
Resolve the unknowns first.
When a static check can't settle the important questions, we propose paid discovery. We agree the investigation and deliverable before it starts.
- Only when more investigation is needed
- Fee and deliverable approved in advance
- Credited once against an accepted build
03 / Once the scope is clear
Fixedscope & price
Finish the work we agreed on.
We quote your actual project, make the approved changes, test the named workflows, and hand over the code and deployment notes.
- Price tied to a defined finish line
- Recurring costs itemized separately
- You retain ownership of your project
Four possible review outcomes
Fixed-scope candidatePaid discovery neededRebuild recommendedNot a fit
The free fit check is a decision about fit. It isn't an implementation plan or a security certification.
Bring your context with you
Your AI already knows the project.
Let it help with the handoff.
You don't need to become a technical project manager to ask for help. Have your coding agent draft the brief, then review it yourself. Plain English is welcome, too.
I'll tell you about it myselfA starting prompt for your agent
“Prepare a project brief for Upforge. Explain what I'm building, who it's for, the workflows that matter, and what isn't working. Include the repository and full commit hash. Leave out secrets and customer data, and let me review it before anything is submitted.”
Connect an agent through MCP
https://upforge.io/api/mcpConnect the Upforge server in an MCP-compatible client. When project review tools are available, ask the agent to submit only after you approve the brief. If they're unavailable, use the review or contact option below.
Before you send it over
Good questions.
Straight answers.
Your project, your code, your call.
See more of our workWhat can I submit?
A GitHub, GitLab, or Bitbucket repository URL with a full commit hash, or a ZIP export. Lovable, Bolt, Replit, v0, ChatGPT prototypes, designer handoffs, and internal tools are welcome. Don't send passwords, production credentials, or customer data.
What does the free review cover?
A static fit check capped at 20 minutes and one clarification round. You'll get one of four verdicts: a candidate for fixed-scope work, paid discovery needed, rebuild recommended, or not a fit. It isn't an implementation plan or a security certification. We don't install dependencies or execute uploaded code.
When is discovery paid?
If the unknowns need investigation beyond the free fit check, discovery is $300 for up to two hours, creditable once against an accepted build. We agree the deliverable and fee with you before starting.
Will you keep what I have built?
That's the starting point. We review what's useful, what's missing, and what would cost more to repair than replace. A rebuild is a recommendation with reasons, not the default.
Who owns the finished project?
You retain ownership of your project and receive the agreed code and handover materials. Third-party components keep their own licenses. Hosting, domains, paid APIs, payment processing, and other recurring costs are itemized separately before work starts.
What does submitting authorize?
A review only. It doesn't authorize code changes, deployment, purchases, paid discovery, or a build. Claims in your brief, including an agent's summary, remain client-reported until we verify them.
How long do you keep private code?
Abandoned uploads are deleted after 24 hours, archives 7 days after review, and reports 30 days after review. Contact details and the request record remain in the CRM under our privacy policy.
You've taken it this far
Let's figure out
what comes next.
Show us what you've built and where you're stuck. We'll start with the free fit check.
- The goal. Who it's for, what they need to do, and what's getting in the way.
- The code. A GitHub, GitLab, or Bitbucket link with a full commit hash, or a ZIP export.
- A safe handoff. Remove passwords, production credentials, and customer data before sharing.
Start with a conversation
Tell us about your project.
A review only. Any paid work needs a separate agreement.
Your project stays yours.Privacy policy
Submitting authorizes a review only. No changes, deployment, purchases, or paid work.Prototype → Production / Upforge