Guide for founders
Budget for the build and the running app.
Use your current plan and service quotes to separate a one-time experiment from an ongoing commitment.
01 — Define the experiment you are funding
A sample-data prototype for three customer conversations has a different budget from a live service that stores records and sends messages. Describe the first outcome, who will inspect it and when you will decide whether to continue. This gives you a boundary for iteration rather than an open-ended build.
- List the screens and actions needed for the first test.
- Separate one-time setup from recurring charges.
- Give the experiment a spending ceiling and a review date.
02 — Read the plan against your requirements
Open current billing and plan information before choosing a subscription. Check the credit allowance, usage rules, project limits, runtime, downloads and publishing options that matter to your project. Record the currency, billing interval and renewal terms alongside the quote so you do not mix annual and monthly prices.
- Write down what happens when included usage is exhausted.
- Confirm which launch and handoff capabilities are included.
- Use current account prices; this guide does not quote a Cocoding tariff.
03 — Add the services your app depends on
A domain, a lead destination, message delivery, payments or storage may introduce separate charges and limits. Check whether runtime is included before adding it again. For each service record the owner, the billing unit and what happens at the limit. Include time or paid help for setup, accessibility, security review and maintenance when those are needed.
- Monthly estimate = subscription + extra usage + runtime + services + annual domain cost ÷ 12 + maintenance reserve.
- Keep one-time setup and review as a separate amount.
- Check taxes, regional prices and usage-based fees in the actual quotes.
- Avoid counting bundled services twice.
04 — Replace guesses with a small trial
Try the same bounded task you plan to build: generate a first version, make two focused changes and test the main flow. Record the actual usage and work that remained. That observation is more useful than comparing subscription labels, but it is still an estimate for a larger project. Review the budget again before inviting more users.
- Save the task, plan, date and observed usage together.
- Model a quiet month and a busier month using the service’s billing unit.
- Set available usage alerts or limits and choose who reviews charges.
- If the ceiling is exceeded, reduce scope or revise the plan before continuing.
A starting point
Make the brief specific.
Adapt this example to your business. Keep sample data separate from real customer information.
Budget worksheet for my first app Goal and review date: ___ Builder subscription / month: ___ Included usage and overage rule: ___ Expected extra build usage / month: ___ Runtime or hosting / month: ___ Connected services / month: ___ Domain renewal / year: ___ One-time setup and review: ___ Monthly maintenance reserve: ___ Monthly ceiling and owner: ___ Assumptions to verify with a small trial: ___
When you need the next step
Follow the product documentation.
Before you start.
Does a lower subscription price mean a cheaper app?
Compare the whole task and ongoing usage. Included capabilities, iteration, services, review and maintenance can change the total. Use equivalent requirements and current quotes for each option.
Can I guarantee a fixed cost from the first prompt?
A prompt does not establish how many revisions, connected services or operating resources the finished app will require. Use a small trial, a spending boundary and explicit assumptions, then revise the estimate as you learn.
Find your next step.
Start with one useful task