Application development
Software built for the problem you actually have
Most business software is a compromise between what a product does and what you need it to do. When that gap costs you more than the software saves, the answer is something built for the way you work. This page is what that looks like, from the first conversation to the code sitting in your own repository.
Before anything is built
The problem gets understood first, and written down
Nobody can specify an application from a feature list, because a feature list is already somebody’s answer. The work starts with the process that is hurting, in the words of the people who run it.
- 01
We watch the work as it is done today
The spreadsheet, the workaround, the step everyone knows to skip, the report someone rebuilds every Monday. This is where the requirement actually lives, and it is almost never what the original brief said it was.
- 02
The problem is written down before a solution is
What the process costs in hours and errors, which parts are rules your business genuinely needs, and which are habits inherited from a system you replaced years ago. You get that written up whether or not you build anything, and whether or not you build it with us.
- 03
Only then is anything designed
A design that solves the problem in front of it, sized to it. Sometimes the honest answer at this point is that configuring something you already own is cheaper than building, and we will say so — a build nobody needed is the most expensive outcome on this page.
- 04
It is built in working increments
Something real runs early and keeps running, tested against the systems and the data it has to live with rather than against a mock. You see it working while it is still cheap to change your mind.
What gets built
Three situations, and what happens in each
A build is one of these three, and which one you are in changes the cost and the risk far more than the technology does.
A new application
“Nothing on the market does this, and we have been coping for years.”
Something that does not exist yet, because the process it serves is particular to your business. Built as a web application your people reach from a browser, or as a service your existing systems call — whichever the problem calls for, not whichever is fashionable.
What you receive
- The application, running in your own cloud account
- Source code in your repository, from the first commit rather than at handover
- Infrastructure defined as code, so the environment can be rebuilt rather than repaired
- The documentation written as it is built, not assembled at the end
Something already designed
“It is specified, and now it needs building properly.”
A design somebody else produced — your architect, your vendor, a consultancy that did the thinking and left. We read it, say plainly where we think it is wrong, and then build what is agreed rather than quietly substituting our own version of it.
What you receive
- The build, against the design as agreed
- A written note of anything in the design we disagreed with, and what was decided
- Tests that run against the real systems it has to integrate with
- A deployment that any competent engineer can run after we are gone
Extending what you already run
“The system is fine. The three things it cannot do are the problem.”
The least glamorous of the three and often the cheapest answer. An extension, an interface, a piece of automation around a system you are keeping — sized so that the thing you already paid for keeps earning rather than being replaced to solve a gap.
What you receive
- The extension, deployed and running against your existing system
- A clear boundary, so an upgrade to the underlying product does not break it
- The same code ownership and the same documentation as a new build
- An honest position on what should be raised with your existing vendor instead
Who owns it afterwards
The code is yours from the first commit
Not on handover, not on final payment, and not subject to a licence from us. It sits in your repository and runs in your cloud account, so replacing us is a commercial decision rather than a technical one. A small firm building your software should expect that question, and the answer should be structural rather than reassuring.
- Your repository, your cloud account, your data
- No runtime of ours to licence and nothing that phones home
- Standard tools and standard patterns, so the next engineer is not learning our dialect
- If you replace us, it keeps running while you do
What we have built and run
Proof, in production
We build and run our own software. PDF Pebble and FairMate are both live on the App Store and Google Play, designed, built and operated end to end by the person who would lead your project — so you can check how we build before you hire it.
FairMate is operated by MyFairMate Pty Ltd, a sister company under the same director. The director holds TOGAF Enterprise Architecture Foundation, AWS Certified Solutions Architect – Associate and AWS Certified Developer – Associate; the full list is on the About page. GTSR is not an AWS Partner Network member, is not a Peppol Access Point, and has not been IRAP assessed.
Start with the process, not the specification
Describe the part of the work that is hurting and how it is handled today. One conversation is enough to say whether building anything is the right answer — and if it is not, we will say so.