Apps & Responsive Web
One codebase gives you iOS and Android apps plus a responsive web experience. Push notifications and payments are already built, and we carry it through store submission and review.
Who this fits
- Services people never return to because they must type the address every time
- Companies where field staff write on paper, then re-enter it back at the office
- Companies that agreed to build an app but never settled what belongs in the app and what stays on the web
How far we take it
Included
- iOS, Android, and responsive web from one codebase
- Screen flow design plus app icon and splash screen
- Push notifications, sign-in, and payments wired up
- App Store and Play Store submission, including review responses
- Store screenshots, listing copy, and a privacy policy page
- Handover of code, store accounts, and documentation
Not included
- Apple and Google developer account fees (Apple yearly, Google one-time)
- Writing the copy and producing photos or video for the app
- Running store ads or marketing campaigns
- Server running costs and third-party fees for push or payments
Build cost by scope
| Scope | Build cost |
|---|---|
| Start smallCore features only | ₩8M~14.8M |
| StandardTypical scope | ₩12.3M~20.8M |
| LargeMany screens, complex | ₩17.4M~25M |
These are example ranges. Once requirements are confirmed you get a fixed quote. Maintenance is billed separately as a monthly plan.
These figures are current as of September 2026. The latest ranges are on the pricing page.
How it runs
- 01
Discovery
We define the core user problem and align on scope and priorities.
- 02
Design
We design the structure and flows, validating fast with prototypes.
- 03
Build
We build maintainable systems with tests and code review.
- 04
Launch
We ship reliably with release automation and store submission.
- 05
Operate
We operate long-term with observability, logs, and metrics.
Frequently asked questions
We read the reason, fix it, and resubmit. That is inside the quote. Rejections are a normal part of shipping rather than an exception, and we check for likely rejection causes before submitting. What we cannot shorten is the review time itself.
It depends on the features. Sign-in, sharing data across devices, push notifications, and payments all need a server. An app that works entirely on the device needs neither a server nor accounts, which is how our own Sales Kit and Quote Kit are built. No server also means no running cost, so we check whether you actually need one first.
Apps go through store review again, so changes are not instant the way they are on the web. Anything expected to change often can be designed to load from the server instead, which lets you edit it without a review. How far to take that is something we decide together, based on what actually changes and how often.
Price follows the number of screens and features, not the number of platforms. Because it is one codebase, dropping the web version saves little, and adding it later costs nothing extra to build. Fewer screens is what actually lowers the number.
Yes. Both stores require a policy URL. Also, collecting nothing is not the same as no data reaching a third party: an app that fetches map tiles collects nothing yet still leaves a record on that server. A mismatch between your store declaration and your policy is itself grounds for rejection, so we write the policy against what actually leaves the device.
Related public docs
Proposals, scope guides, and build examples we publish openly.
A vague scope is fine
Tell us where things stand and we will point to the scope you need and a rough size.