Web app
A product people can try through a browser link
What's included
- Core workflow and interface
- User accounts where needed
- Data storage and agreed integrations
- Repository handoff
A focused first release that tests your product idea through one complete user journey.
Deliverable 1: A first-release brief with a user, a problem and a testable assumption
Deliverable 2: A clear feature cut: needed now, manual for now, or later
Deliverable 3: The core user journey implemented from entry to outcome
Deliverable 4: Only the accounts, data and integrations that journey needs
Deliverable 5: Milestones, acceptance criteria and a weekly working demo
Deliverable 6: Repository handoff and a separate backlog for the next release
A product people can try through a browser link
A product whose first use needs an iPhone app
| Scope | Web app | iPhone app |
|---|---|---|
| First release | A focused browser workflow | A focused iPhone workflow |
| Distribution | A web deployment in your accounts | Submission through your Apple developer account |
| Backend | Only the accounts, data and integrations needed now | Backend connections needed by the agreed app flow |
| Later features | A separate backlog, outside the initial quote | Android on request; additional app features scoped separately |
| What it establishes | A usable release for testing your assumption | A usable app for review and product testing |
Describe the user, the problem and the behavior that would make the first release useful.
I separate essential features from manual steps and later ideas, then quote milestones and timeline.
Weekly demos connect the core flow end to end, instead of accumulating disconnected screens.
I hand over a verified scope and the code. User feedback informs the next backlog; the first build does not prove demand.
A web MVP starts from $12,000; an iPhone MVP starts from $20,000. MVP describes a focused release, not a separate discounted price tier. The fixed quote lists exactly which workflow and features it covers.
An MVP limits the release to what is needed to test a product assumption. A broader web app project can cover an established operation with more roles and workflows. A polished first release still needs working permissions, data handling and failure states.
Yes, if the first use case works well in a browser. That avoids committing to an app before it is needed. I can plan shared data and backend boundaries, but a later app remains its own design, build and release scope.
I built Linkbuk as a web product and iPhone app with profiles, booking and payments. Its card below shows the real mobile website, and its case links to the App Store listing. This demonstrates a shipped product without promising traction or a matching delivery timeline.
No. I take paid projects with a written scope, price and milestones. Fundraising, customer acquisition and proof of market demand are outside the build; I do not exchange development for equity.
New ideas go into a separate backlog unless the written scope is revised. Weekly demos make tradeoffs visible. I do not keep adding features under the original price, and the release date is agreed with the quote rather than promised in advance.