There are three different jobs hiding inside “build an app.”
First, you have to decide what is worth building and how you are going to release it. Then you have to make the app dependable enough to keep its data somewhere useful. After that, you still have to give people a reason to find it.
Those jobs overlap, but they are not the same job.
I kept running into the same decisions across my own apps, so I finally turned the workflow into three small playbooks. They are not meant to replace thinking. They are meant to keep me from starting from a blank page every time.
1. Start with the product, not the feature list
The Solo App Launch System is the first step.
This is the part that helps answer the questions before the code gets too far ahead:
- Who is this for?
- What problem is specific enough to explain in one sentence?
- What is the smallest useful version?
- What has to be true before it is ready to release?
- How will I know whether anyone actually cares?
I have learned that a roadmap can look productive while avoiding all of those questions. More screens do not automatically create a better product. A smaller scope with a clear reason behind it is usually a better place to start.
The launch playbook connects the product brief, the build, the App Store submission, the first marketing work, and the measurement loop. It is for the part of the process where an idea needs to become a real thing without turning into a six-month project.
2. Decide whether the app needs a backend
Some apps should stay local.
If the product is useful on one device, does not need shared data, and does not need an account or server-side process, local storage may be the right answer. There is no prize for adding Postgres to an app that does not need it.
Other apps eventually need more. Maybe data needs to sync between devices. Maybe several people need to see the same records. Maybe the app needs a durable API, background work, or a database that can grow without shipping a new binary for every structural change.
Ship the Backend is the playbook for that transition.
The goal is not to draw a giant architecture diagram. The goal is to take one real feature across the boundary and prove that it works.
The kit walks through the decisions and the implementation around a small Notes vertical slice:
- a clear API contract
- a .NET 8 Web API
- PostgreSQL and numbered migrations
- Docker Compose for local development
- validation and problem details
- health and readiness checks
- tests and GitHub Actions CI
- a Render deployment path
That gives the workflow somewhere concrete to start. You can see the request, the persisted row, the test, and the production check. The backend is no longer an abstract future concern.
It is also intentionally narrow. Not every app needs authentication, payments, queues, microservices, or a complicated cloud setup. Adding those because they might be useful someday is how a small product becomes a systems project before it has users.
3. Make the work visible
Building the app is only part of the job. A good app can still disappear if nobody sees the moment that makes it useful.
The Short Video Factory is the playbook for turning real app footage into something people can understand quickly.
The important word is real.
The process starts with choosing one useful moment, making the app predictable enough to record, and capturing the flow instead of trying to explain the entire product at once. From there, the kit helps turn one recording into a few different tests:
- a short vertical clip
- several hook variations
- a captioned Reel, TikTok, or Short
- a 4:5 carousel or slideshow
- a posting log and a simple performance review
The scripts handle the repeatable parts. The builder still has to decide what is worth showing.
That distinction matters. Automation can make five versions of a weak idea very quickly. It cannot decide which user problem deserves the first two seconds of the video.
How the three pieces fit together
The workflow is fairly simple:
- Use the launch playbook to choose the problem, audience, scope, release plan, and measurement question.
- Build the smallest version that can answer the question.
- Keep the app local if local is enough. If the product needs shared or durable data, use the backend playbook to move one feature to an API and database.
- Use the video playbook to record a real moment from the finished app and prepare a few honest ways to show it.
- Keep the results in the loop. UseManifest is the place I am building for App Store Connect records and store-funnel measurement across the portfolio.
The order is useful because it keeps the work connected. The marketing is not invented separately from the product. The backend is not added separately from the user problem. The measurement is not an afterthought that starts months later.
Which one should you start with?
If you are still deciding what to build, start with The Solo App Launch System.
If you have a working local app that now needs an API and database, start with Ship the Backend.
If the app works but you need a repeatable way to show it, start with The Short Video Factory.
You do not need all three on day one. They are separate because the problems are separate. But together they cover the part of app building that tends to get skipped: choosing carefully, building a durable boundary when it is needed, and giving the finished work a chance to be seen.
That is the workflow I am using now. It is not magic, and it does not guarantee downloads or sales. It just makes the next decision clearer and makes the work easier to repeat.