How to build an app without technical knowledge: a non-technical founder’s playbook

You can build an app without technical knowledge by owning the problem, the customers and the decisions, and hiring people whose work you can check. You don’t need to code. You do need to work in the right order, and to ask builders hard questions before you sign.

You also need to know that everything you’re paying for can come to you. That doesn’t mean every account has to sit in your name from day one. It means a written agreement that it all transfers when you need it, and a setup that makes the move clean.

Most founders we meet think the risk is their own lack of technical skill. It isn’t. The risk is the partner they choose.

“The fear of failure is picking the wrong technology partner and that they will drag you like an anchor.”

This is the order we’d follow, from idea to launch, with the mistakes that cost founders most along the way.

Feel like you’ve been dropped into a foreign technology world?

That’s how many founders describe it. Every week brings the next hurdle, in a language you don’t speak.

One founder came to us with an app she had never seen working. Her offshore team, eight weeks out of a coding bootcamp, had built something she couldn’t run on her own phone. She needed it in the App Store, and she had no way to check what she’d paid for.

None of that was her fault. It’s what happens when nobody on your side can see the work. Every step below is designed so that you always can.

I have an app idea. Where do I start?

Start with the problem, not the app. An app is one possible answer to a problem. If you lead with the solution, you’ll spend months building features nobody asked for.

Write one paragraph that answers four questions:

• Who has this problem? Be specific: “independent physios in the UK”, not “healthcare”.
• How do they deal with it today?
• What does that cost them in time, money or stress?
• Why hasn’t anyone fixed it already?

If you can’t answer the last question, that’s the first thing to find out.

Step 1: talk to twenty people who have the problem

Before design, before code, have twenty conversations. Ask about their last experience of the problem, not whether they’d use your app. People are polite about ideas and honest about their past.

Better still, ask for money. Friends and family will tell you your idea is great. A request to pre-order is a much sharper test. Our guide to validating an app idea has the questions we use.

Step 2: decide the first version worth launching

Your first version should do one job well for one type of user. It has to be good enough that people pay, or come back, not just good enough to demo. Everything else goes on a “later” list.

A useful test: what’s the one action a user must complete for your product to have worked? For a delivery app, that’s booking a delivery and getting it. Anything that isn’t needed for that action can wait.

Step 3: agree who holds the accounts, and how they move to you

Settle this before anyone builds anything. An app runs on a handful of accounts:

You have two sound choices.

Everything in your name from the start. You open each account, and your builder is invited as a user. You hold the keys throughout. You also deal with the sign-ups, the billing and the paperwork.

Your partner holds them, set up to transfer. Your partner opens and pays for the accounts during the build, and often afterwards. You get a written right to have everything moved to you whenever you ask. This keeps the admin off your desk while you focus on customers.

Either works. What doesn’t work is the second option without the agreement, or with a setup that can’t be moved. That’s how founders end up unable to leave.

On LaunchPad, the accounts sit with you or with us during the build, as you prefer. They’re yours at launch either way, and the costs sit in the fixed price.

What does a clean transfer look like?

A transfer is clean when the thing you’re given is whole: the live product, its history and its users. It isn’t clean if someone has to rebuild it in a new account. Here’s what to look for in each case.

Hosting on AWS

Your product should live in its own AWS account, with nothing else in it. Your partner can run that account under their AWS Control Tower setup. That gives them central security rules and billing across all their clients.

The test is whether your product can leave as one piece. An account can be unenrolled from Control Tower without being closed or deleted. It can then join your company’s own AWS setup by invitation, or stand alone. Servers, data and history go with it.

The setup to avoid is your servers mixed into the agency’s own account. Then there’s nothing to hand over, and everything must be copied across piece by piece.

That’s how we run hosting: each client product gets a whole AWS account under our Control Tower, ready to move out to the client.

App Store and Google Play

Apps can move between developer accounts and keep their users. Apple’s app transfer keeps the app’s ratings and reviews, and existing users keep getting updates. Google Play transfers users, ratings, subscriptions and store listings too.

On both stores, past sales reports stay behind and test groups must be set up again. Ask for the reports to be exported first.

Your company will need its own developer accounts to receive the apps. Companies need a free D-U-N-S number, a business ID. Apple says it can take up to five business days to issue. Google won’t open an organisation account without one. Start early.

Avoid a personal Google account for the business. New personal accounts must run a closed test with at least 12 testers for 14 days before going live.

Code on GitHub

A GitHub repository can be transferred to another account or organisation. Its full history, issues and settings move with it, and old links redirect. If your partner set up a GitHub organisation just for your product, ownership of the whole organisation can pass to you too.

The setup to avoid is your code sitting inside a shared repository with other clients’ work. That can’t be transferred cleanly.

Your domain

Ask for your company to be named as the domain’s registrant, the legal owner, from day one. Your partner can still manage the settings. Moving registrar later then needs only a transfer code, which your registrar must provide within five days.

If the registrant changes later instead, many domains then can’t move registrar for 60 days. It’s simpler to get the name right at the start.

Payments and analytics

A payments account like Stripe is tied to the business that takes the money. Open it in your company’s name from the start, and invite your builder. Do the same for analytics if you can, so your data history is never in question.

What should the contract and handover cover?

Put these in the contract:

• The code, designs and other IP are assigned to your company. Read who owns your code before you sign.
• Every account is listed: domain, hosting, repository, stores, analytics and any third-party services.
• Each one transfers to you on written request, at any time, not only at the end.
• Your product runs in its own AWS account and its own repository or GitHub organisation.
• Your company is the domain’s registrant.
• The partner will cooperate with every transfer, within a stated number of days.
• What a transfer costs, if anything, is written down now.

At handover, check you have:

• Admin access to every account, with the partner removed or reduced to a user.
• The AWS account in your organisation, or standing alone with your company’s billing.
• Root access for the AWS account, on an email address your company controls.
• The apps in your developer accounts, with exported sales reports.
• The repository in your GitHub, with its full history.
• Passwords, API keys and other secrets, sent securely and then changed.

Step 4: choose who builds it, and test them

You have three broad options: a freelancer, an agency or studio, or a fractional CTO leading a team. A fractional CTO is a part-time senior technical leader. We compare the three in agency vs freelancer vs fractional CTO.

You don’t need to read code to judge a team. Ask any of them three questions:

• How often do you deploy, meaning put new code live?
• How long does a change take to reach a customer?
• How often does a deploy break something?

A strong team deploys often and rarely breaks things. If a small change takes a month, expect that pace for the life of your product.

Step 5: see it before it’s built

Insist on a clickable prototype before development starts. A prototype looks and feels like the real app, but nothing behind it works yet. It costs a fraction of the build to change.

Put it in front of five of the people you interviewed, and watch without helping. Where they hesitate, your product is confusing. Fixing that in a prototype takes hours, not weeks.

Step 6: build the riskiest part first

Ask your builder to start with the hardest, most uncertain feature, not the login screen. For a delivery app, that might be matching parcels to the right drivers. If it can’t be done, you want to know in week one, not month four.

“You need to start with the most difficult and high risk thing.”

Then ask to see it running on a real phone within the first week or two. Not a slide or a screen recording: the app, on your device. That one request would have saved the founder who couldn’t see her own app.

Step 7: stay on the customer’s side of the build

You shouldn’t have to care about code reviews or technical debt. Your job is customers, finances and investors. Take part in the build from the customer’s side instead:

• Attend a weekly demo of working software, not slides.
• Comment on designs in Figma, the design tool most teams use, before they’re built.
• Answer questions within a day, because waiting stalls the team.
• Say no to new ideas mid-build, and park them for version two.

Step 8: test with real users, then launch and measure

Run a beta, a short test with a small group of real users, before you go public. Give them real tasks and watch what breaks. Bugs found by twenty friendly testers are cheap. Bugs found in your first one-star review aren’t.

Launch is the start of learning, not the finish line. Agree two or three numbers that tell you it’s working: sign-ups, people completing the core action, and people coming back a week later. Allow time for app store review, because a rejection can delay launch by days.

Then decide who runs the product: you, or your partner. We can run it with TotalCare, our fixed monthly service covering hosting, the store accounts, third-party services and support. Either way, the transfer agreement still stands.

What should you ask any builder before you sign?

Use this checklist with anyone, including us:

• Can I see a live product you built, and speak to that client?
• Who exactly will do the work? Are they employees or subcontractors?
• Will I see the hardest feature working on my phone in the first week or two?
• Is the price fixed? What happens if I want to change something?
• Does the contract assign all IP to my company?
• Is it written down that every account transfers to me when I ask?
• Will my product have its own AWS account and its own repository?
• If you disappeared tomorrow, what would I have?

Then notice how they answer. A good partner explains how a transfer works without hesitating. A bad one makes you feel stupid for asking. If you leave a meeting feeling that way, keep looking.

What does this look like in practice?

Ultra Goldfield Logistics spotted a gap in last-mile parcel delivery, matching people sending parcels with drivers already on the road. Before committing to a build, the team phoned round and knocked on doors to see who’d use it and pay. Then they took a clickable prototype back to the same people. A competitor analysis checked the gap was real and defined who the users were.

Then we built a brand, a customer portal for booking deliveries and a driver app for accepting jobs. The driver app shows each driver the parcels nearest their route, and it collects data for smarter routing later. The first version was delivered in three to four weeks, on a deliberately tight scope.

The order is the point. Validate, decide the users, then build the smallest thing that serves them.

If you’re ready to turn your idea into a product, see how LaunchPad works. Then talk to us. We’ll start with your problem and your customers, and we’ll show you exactly how everything comes to you.