Discovery & prototype
Test the idea and plan the smallest useful first version before a large build.
Best when the idea is earlyBrand development / App development
From app idea to working product.
Bring us an early idea, an existing product, or a problem an app could solve. We can produce the requirements, prototype, interface, working build, test plan, launch materials, and support plan the product needs.
Types of app project
What could the product become?
The people using it, the work it should make easier, and the features it needs will shape the team, schedule, and budget.
Mobile product
An iOS, Android, or cross-platform app designed around phone behaviour, device capabilities, and store release.
Native or cross-platformWeb platform
A customer portal, marketplace, dashboard, booking system, or other service used in a browser.
Public or account-basedInternal system
A tool for team tasks, reporting, approvals, or information that is spread across several places.
Built around real workIntegration & automation
Connect existing services and reduce repeated manual steps without replacing everything.
Works with your current toolsOngoing product
A live app that needs regular updates, maintenance, support, and improvement.
Managed over timeWhat affects the priceHow much it does
Number of screens, user types, tasks, and special cases.
What affects the priceTechnical features
Accounts, payments, messaging, location, AI, connections, and data.
What affects the priceTesting and launch
Research, design, testing, moving data, publishing, and support.
What affects the priceDeadline
How quickly the work is needed and how fast decisions can be made.
Examples of apps
Start with the task people repeat.
The right app is shaped around its users, daily work, existing systems, and budget. These examples show possible first versions, not fixed feature lists.
Guest & loyalty app
Bookings, registration, loyalty points, offers, check-in information, hotel requests, restaurant or spa reservations, and a digital key where the property system supports it.
See the hotel project example →Ordering & rewards app
Customer accounts, points, order ahead, click and collect, favourites, payments, personalised offers, and clear order updates.
See the café project example →Booking & membership app
Memberships, class booking, waitlists, passes, payments, reminders, trainer updates, and simple account management.
See the fitness project example →Tenant & maintenance app
Issue reporting, photos, appointment updates, documents, notices, contractor assignments, progress tracking, and a record of completed work.
Ticketing & member app
Registration, programmes, tickets, member access, schedules, venue information, notifications, offers, and post-event content.
Internal team app
Staff tasks, approvals, checklists, stock or asset records, field updates, reports, and connections to the systems the team already uses.
Booking engines, payments, property systems, customer databases, digital keys, and other third-party tools are reviewed before they are included in the scope.
A practical route
Fund one clear stage at a time.
The first proposal recommends the smallest useful stage. Each stage has its own deliverables, schedule, responsibilities, and price before work begins.
01 / DefineScoped stage
Product definition
Clarify the problem, users, workflows, constraints, and the smallest useful release before committing to a build.
- Product objective and audience
- Core journeys and requirements
- Recommended first release
02 / PrototypeScoped stage
Prototype and interface
Make the main journeys visible and testable before engineering decisions become expensive.
- Information and screen structure
- Interactive prototype
- Design direction and test notes
03 / BuildProject quote
Build and launch
We choose and manage the people needed to build, test, prepare, and release the agreed product.
- Product and interface design
- Web, mobile, backend, or integration development
- Testing and release preparation
- Launch, handover, and early improvement
04 / ContinueSeparate scope
Support and releases
Plan fixes, platform updates, user feedback, and new releases after the initial handover.
- Support responsibilities
- Release priorities and review cycles
- Quoted maintenance or improvement stages
Price depends on the stage, type of app, features, platforms, integrations, team, testing, and deadline. The written scope and quote come before paid work. Any material change to time or cost must be approved first.
Ownership and handover
The written scope lists the accounts, licences, source code, design files, documentation, store access, and support responsibilities included. The agreed work is handed over after the relevant invoices are paid.
A live example
Pinglo: one idea, now a live app.
Pinglo began as one everyday problem and is now a live App Store product. Your app can serve a completely different customer, organisation, or workflow.
Common questions
What clients ask first.
Do you only build community apps?
No. We work on consumer products, company workflows, customer services, internal tools, operational systems, and other focused app ideas.
Can I come with an early idea?
Yes. A rough idea, repeated task, or problem that should be easier is enough for the first conversation.
How is the work priced?
The quote follows the product stage, platforms, workflows, integrations, professional roles, testing, launch work, and support required. Scope, schedule, and price are agreed before paid work begins.
How long does development take?
Time depends on the product stage, platforms, features, integrations, testing, review speed, and launch requirements. The proposed schedule is included with the written scope.
What will be handed over?
The scope lists the app build, source code, design files, documentation, accounts, store access, and support included. Handover happens after the agreed delivery and relevant invoices are complete.
Can you support the app after launch?
Yes. Support can cover fixes, platform updates, user feedback, new features, release preparation, and ongoing product planning through a separate support stage or partnership.
Start here
What should the app make easier?
You do not need a technical document. Tell us the problem, who has it, and what you want the app to make easier.