A small iPhone or iPad app, built from scratch
You do not need a finished specification to write to me. Start with what someone should be able to do in the app. I can work out the first screens from that.
Discuss an appFour apps I have built
I came up with, designed and developed these apps. Their project pages show the screens and explain some of the decisions behind them.
Find the main use case first
We choose one complete use case: who opens the app, what they do and what they get at the end. That gives us a basis for the screens and scope before development starts.
- Who would open the app, and why?
- What should they be able to do in the first few taps?
- What data or content do you already have, and what still needs to be made?
A shopping list on one iPhone
This example covers adding items at home and checking them off in the shop. It illustrates a bounded first version; it is not an account of BAGGO’s original release.
- A list and an add-item form: enter a name, save it, check it off, undo the check or delete the item.
- Data stays on this device. Items and their checked state survive closing the app; the main use case works offline.
- Sharing, accounts, syncing, voice, photos and payments are outside this version. Each addition changes the scope.
From screen map to a build on your device
- 01
Use case and screens
We write a brief covering the user, task, start and end of the use case, data and constraints. I show the screens and states, including empty data and input errors.
- 02
Design and code
I design the interface and build it with SwiftUI. We agree on devices, iOS versions and a way to share interim builds for testing.
- 03
Prepare for release
We test the agreed use case. If you need the App Store, we scope build preparation and review materials as part of the work. Apple makes the final decision on approval.
How we check the result
Before development, we write down the expected result of the main use case. On a working build, we check the normal path, empty states, input errors and data persistence. We test offline use if it is part of the scope.
We compare feedback with the agreed scope. New features and changes to the use case are discussed and estimated separately.
What you receive at handover
You receive the source project, a working build for the agreed installation method, build instructions, a dependency list and test results. If the app uses external services, we record which accounts and settings it needs.
What affects cost and timing
The estimate depends on the use case and its states, devices, available materials, data storage and external services. After the brief, we agree on the first-version scope, schedule, price, how corrections are handled and any release assistance.
I build small new products for iOS. I do not take on Android or large systems with substantial backend work. If your idea depends on accounts, syncing or complex payments, tell me before we estimate it.
The Apple Developer account is registered and paid for by you. I can help with publishing, but the app and account stay yours.
Before we discuss your project
Use a brief to describe the task, gather materials and agree how to check the result.
Tell me about your app idea
Tell me who the app is for, what they should do and the result they need. Include any materials you have. I will clarify the constraints and propose the first-version scope, timing and cost.
Discuss an app