For the build that hasn't picked a platform yet
Application Development Services
Not every build starts with a platform already chosen, and that is not indecision, it is honesty about an unproven idea. This practice frames the problem, tests it against real users, and builds on whatever platform earns the decision, whether that means web, mobile, an internal tool, or all three.
How the platform decision actually gets made
Framing the problem before committing to web, mobile or anything else.
90 secSample frame · video pending01Before naming a platform
Choosing a platform before choosing a technology
Most platform decisions get made by momentum: whatever the last project used, or whoever is in the room. Four questions settle it against the actual users instead.
Where do your users already spend their time?
A workflow tool for people already living in email or Slack often fits there before it fits inside a new interface nobody has opened yet.
Does the work need to happen offline or on hardware?
Camera access, offline use or sensor data point toward a dedicated app. A browser-based tool serves everything else more cheaply.
How many distinct groups need access?
One user group tolerates a single simple build. Several groups with different needs often justify separate interfaces sharing one core.
Is the requirement still changing weekly?
An unstable requirement is a reason to build the smallest useful version first, on whichever platform proves the idea fastest.
| Web application | Dedicated app or platform-specific build | |
|---|---|---|
| Best when | Users are already at a screen with a browser | Offline access, hardware or store presence matters |
| Time to first version | Faster, fewer moving parts | Slower, more platform-specific work |
| Reach | Immediate, no install required | Requires install or store approval |
| Natural next step | Stays a web application | Specialises into mobile, enterprise or another shape |
02Agreed before the build starts
The ledger that keeps an undecided shape honest
Application engagements drift when 'figure out the platform later' quietly becomes nobody deciding, and the build assuming one anyway. This ledger sets what you bring, what we test, what comes back, and what stays yours.
- Your side
You bring
- The problem you are solving and who has it
- Any constraints on budget, timeline or existing systems
- Whatever early sketches, notes or research already exist
- Our side
We build
- A platform recommendation weighed against your actual users
- A working build on whichever platform fits best
- A path to specialise further once the shape is clear
- Your side
You receive
- Software running on the platform that earned the decision
- A documented rationale for why that platform was chosen
- A codebase ready to specialise or extend later
Never leaves you
- The final call on which platform to commit to
- Product direction and every roadmap decision after launch
- All intellectual property from the first line of code
Where the line sitsWe help settle the platform question with evidence, not preference. The decision itself, once made, stays yours to defend.
03From an open question to a running build
Four stages, each closing on evidence
A build that guesses its platform usually skipped a stage here. This system closes each one with a decision recorded before the next stage begins.
Frame the problem before the platform
The actual need gets written down before any platform is named, so the build serves the problem rather than a habit or a preference.
A problem stated plainlyTest the platform against real users
Where users already are, what device they carry and what the work actually requires settle the platform question with evidence, not a guess.
A platform decided on evidenceEngineer for the shape that won
The build runs on the platform the evidence supported, structured so it can specialise into mobile, enterprise or another shape without a rewrite.
A build that can specialise laterRoute toward a deeper specialism if one appears
If the shape sharpens mid-build, toward mobile, enterprise or a specific platform, the engagement hands off cleanly instead of forcing a generalist fit.
A route to the next specific page
04What actually moves the number
Four drivers, priced from the assessment
Application work is priced against the assessment, because these four factors change scope well beyond a simple feature count.
Number of platforms in scope
One platform costs less to build and maintain than several shipping at once, though a shared core narrows that gap.
How settled the requirements are
A requirement still changing weekly costs more to build against than one already validated with real users.
Integration with existing systems
Connecting to systems you already run adds real engineering, distinct from building a standalone application with no dependencies.
Depth of testing and release discipline needed
A customer-facing launch justifies more release rigour than an internal tool used by a small, forgiving group of employees.
05Evidence and proof
Builds that found the right platform before committing to one.
Application development proof is a platform decision that held up after launch. Every record here waits for written client approval before production.
Explore case studiesA prototype that had quietly run the business for a year became production software.
Vela Ledger's billing logic lived in a spreadsheet-fed script nobody wanted to touch. A production application replaced it around the logic that already worked, without losing a single historical record.
- Historical records migrated
- All, zero loss
- Time to production
- Under one quarter
One shared core served three different user groups instead of three separate builds.
Orra Systems needed customers, administrators and field staff each served differently from one workflow platform. A shared application core avoided duplicating the same logic three times over.
- Separate builds avoided
- 3 to 1 shared core
- User groups served
- 3
We genuinely did not know if this belonged on web or mobile yet. Framing the problem first was the right call.
Sample · pending client approval
06Read this first
When a generalist build is the wrong starting point
Booking a broad, undecided engagement when the platform is already obvious spends time proving what nobody doubted. The exits below route straight to the page that already fits your shape.
- Enterprise app development
The buyer is enterprise IT, not a product team
Internal, business-process software for a large organisation carries different concerns entirely. Enterprise app development speaks to single sign-on, legacy data and internal adoption directly.
- Cross-platform app development
The build is already known to be one shared codebase
When the real question is the shared-codebase trade-off itself, cross-platform app development goes deeper on exactly that decision.
- Hire Developers
You need capacity on a stack your team already owns
If the stack and the architecture are already decided, hiring directly into that stack is faster than a generalist build.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Platform assessment | The shape is genuinely still open | Constraints and priorities | The platform decision and rationale |
| Scoped build | The shape is decided but bounded | Acceptance and priorities | Engineering and delivery |
| Delivery pod | The shape may evolve as users respond | Product decisions each cycle | Engineering, quality and releases |
07Straight answers
Asked before the platform question is settled.
01We don't know yet if this should be web or mobile. Can you still start?
Yes, that uncertainty is the normal starting point here. Framing the problem and testing it against real users usually settles the platform question early, before much budget is spent.
02How is this different from mobile app development?
Mobile app development assumes the platform is already decided. This practice exists for the stage before that decision, when the shape of the build is still genuinely open.
03How is this different from custom software development?
Custom software development answers whether to build at all against buying a product. This practice picks up once building is the answer, and settles which platform it should run on.
04What if the platform decision turns out to be an internal enterprise tool?
The engagement hands off cleanly to enterprise application development, which speaks directly to internal systems, single sign-on and adoption inside a large organisation.
05Do you build the prototype, or replace an existing one?
Both, depending on where you start. Many engagements begin with an existing prototype or spreadsheet-based tool that needs to become production software without losing what already worked.
06What does application development cost?
Cost is priced against the number of platforms in scope, how settled requirements already are, and integration with your existing systems. An undecided platform costs less to assess than to build twice.
07Can this route into a more specific practice partway through?
Yes, if the shape sharpens mid-build toward mobile, enterprise, or a specific platform, the engagement routes there directly instead of forcing a generalist fit.
08How long before we see something working?
A working version on the platform the evidence supports typically exists within the first few weeks, well before every feature is finished.