When the spreadsheet stops coping.
Portals, dashboards, booking and internal tools, programmed around the process you already run.
What it is
Most internal tools start as a spreadsheet that worked. Then it grew three tabs, then it grew a person whose job is to fix it every Monday. That is the point where a small application starts paying for itself.
We start from the process as it actually runs rather than as the org chart describes it, and build the smallest thing that removes the manual step. Whatever a standard platform already does well, we leave to the standard platform.
| Role | Can see | Can do |
|---|---|---|
| Owner | everything | everything, including user management |
| Staff | own team's records | create and edit, no deletion |
| Accountant | invoices and exports | export only |
| Client | own orders and documents | upload, comment |
| API token | scoped endpoints | read, or write where granted |
Who can see and do what, agreed in the scope rather than discovered after launch.
What you get
- A written scope covering screens, roles and what happens at each step
- A clickable prototype before the code, while changes are still cheap
- The application itself, in short milestones on a test link
- Roles and permissions, so the right people see the right thing
- Integrations with the tools you already run
- Data export, so your data is never locked in
- Handover of the code and the accounts, with a written note on how it fits together
- A maintenance arrangement if you want one
How it is built
- Scope
- Screens and rules agreed in writing before any code
- Prototype
- Clicked through by you, so changes happen on paper
- Milestones
- Each one reviewed on a test link, not at the end
- Permissions
- Who can see and do what, decided early
- Exit
- Your data exportable, your code yours
Questions
Is this cheaper than buying software?
Often not, and we will say so. Custom pays off when the standard tool forces you to change how the business works, or when you are paying per seat for something you use ten percent of.
Can it talk to the systems we already use?
That is usually the point. If a system has an interface, it can be connected; if it does not, we will tell you before you build on that assumption.
What if we want to take it in-house later?
Then you take it. The code is yours, the accounts are yours, and the handover is written for a developer who has never seen it.
Often taken together
Need web applications?
Send the address of your current site and say what you want to achieve. You get questions back, then a plan and a price.