Not every problem needs an application, and saying so is part of the job. Where one is the right answer, it is built in stages small enough that you can put each one to work before the next is agreed — which is also how a budget stays under control.
Organisations running a process on paper or in spreadsheets, teams that need a portal for customers or partners, and businesses whose current tool has outgrown the way they now work.
We write the process down as it runs today, including the parts done on paper, in a spreadsheet or in somebody's head, and then decide which of them software should replace. That step is what stops a project from rebuilding a process nobody wanted in the first place.
A first stage a team can genuinely work in is worth more than a demonstration of everything half-built. Each stage is used, reviewed and signed off before the next begins, so nothing is built on an assumption that nobody has tested with real work.
An application that runs well on a development machine and badly on a mid-range Android phone is not finished. Screens are tested on real devices, with attention to how much data they use and what happens when the signal drops in the middle of a task.
The code, the accounts and the deployment process belong to you, and they are documented while the person who built them is still around. A system only one person knows how to deploy is a risk a business carries without noticing it has one.
Often a website is enough, and it is cheaper to build and to maintain. An app on a phone earns its place when the work needs the camera, use without a connection, notifications, or a task somebody repeats many times a day. We will say which of those apply to you before any scope is written.
Part of it can. Data entry can usually be held on the device and sent when the connection returns, which means deciding who wins when two versions of the same record disagree. Anything needing a live answer — a stock level, a payment — cannot honestly promise to work offline, and we say which parts of your process sit on which side of that line.
You do. The code, the accounts and the documentation are yours, and the handover is written so an in-house team or another developer can take it on. We are glad to keep supporting it, or to step back, but that is your decision rather than a consequence of how it was built.
Whatever the application runs on has to be watched, backed up and updated once it is carrying real work.
Anything holding customer data, payments or staff records is tested before it goes public, while the fixes are still cheap.
An application and a website usually share accounts, design and content, so they are planned together rather than as two separate builds.
A short description of the project is enough to start. We will reply with how we would approach it, what it needs and what it would take.
