Drag
loader

Contact info

Email
hello@ferressystems.com.au
Based in
Melbourne, Victoria

Follow us

Talk to the team
Talk to the team
All services // CUSTOM SOFTWARE AND INTEGRATIONS

The tool nobody sells, because it is yours

A spreadsheet is running part of your business, one person understands it, and everybody is slightly afraid of it. It is rarely the only one.

Internal tools and dashboards, client and customer-facing portals, integrations between systems that were never meant to talk, reporting and data work, workflow automation, and taking over software somebody else built and left. The runaway spreadsheet is the most common way this starts, not the limit of it. Secure from the first line rather than reviewed at the end, and owned outright by you.

Scope this with us
 Free: The short build brief
// SOUND FAMILIAR

If two of these sound familiar, we should talk

The rest of this page covers what the work includes, what it produces and how it is priced.

01 A critical process lives in a spreadsheet that only one person can edit
02 You pay per seat for software where you use about a tenth of it
03 Two systems you rely on do not talk, so somebody retypes between them
04 An application you depend on was built by someone who has since moved on
05 Getting a straight answer out of your own data takes somebody a day of copying and pasting
06 The off-the-shelf product almost fits, and the gap is where all the work goes
// THE SCOPE, BOTH SIDES OF IT

What this is, and what it deliberately is not

What this is

  • Internal tools and dashboards built for a job you can describe in a sentence
  • Client and customer-facing portals where the off-the-shelf option does not fit how you work
  • Integrations between systems that were never designed to talk
  • Reporting and data work, so a question about your own business does not take a day to answer
  • Workflow automation that removes retyping rather than adding a new place to type
  • Taking on an application somebody else built, documenting it, and making it safe to change
  • Security built in from the start: authentication, access control, logging, sensible data handling
  • Code and infrastructure you own, documented so another developer could pick it up

What this is not

  • A build of something you could buy for less
  • A per-seat licence with our name on it
  • A prototype handed over as production
// THE ENGAGEMENT, START TO FINISH

What actually happens after you say yes

Typically six to twelve weeks for a first release

We aim to get something genuinely usable in front of your team early, then iterate, rather than disappearing for three months and returning with a surprise.

01

Understand the work

We watch how the job is done now, including the workarounds people are slightly embarrassed about. Those workarounds are the requirements. We also check whether you should just buy something instead.

02

Shape and scope

What the first release does and, more importantly, what it deliberately does not. Written down, with the things we agreed to leave out listed by name so nobody misremembers later.

03

Design the data

What information the system holds, who can see it, how long it is kept and where it lives. Doing this before the build is why security ends up designed in rather than bolted on.

04

Build in the open

You see working software regularly rather than status reports. Feedback arrives while changing things is still cheap, which is the entire point of working this way.

05

Security review and hardening

The application gets reviewed and tested by the same people who do our penetration testing, before your staff depend on it.

06

Launch and hand over

Live, with your team trained on it, the code and infrastructure in your ownership, and documentation written so somebody other than us could take it forward. Who maintains it afterwards was agreed at scoping.

// WHAT YOU WALK AWAY WITH

Things you can hold, forward and act on

The artefacts this work produces, named so you know what you are buying.

Written document

Requirements and scope

Including a named list of what the first release intentionally leaves out

Written document

Data and access design

What is held, who can see it, how long it is kept

The thing itself

The application

Running, with source code and infrastructure owned by you

Written report

Security review

Done before launch by our testing team, and included in the price

Written document

Technical documentation

Written so another developer could pick it up

Live walk-through

Training session

For the people who will actually use it every day

// NOT A MOCK-UP

The box people want to skip

A page straight out of the short build brief, shown as it is. Read the page, then decide whether the whole document is worth an email address.

The Short Build Brief SECTION 03 OF 12 // WHAT THE FIRST RELEASE EXCLUDES

Not in version one, and we have agreed that. This is the most valuable box on the page and the one people want to skip. A project with no exclusions has no scope.

HOW THE TABLE WORKS
  • One numbered row per feature discussed and consciously set aside, by name
  • A "revisit when" column against each, so setting something aside is not the same as refusing it
  • Room for anything you are choosing to keep doing manually for now
  • Room for every system you are choosing not to integrate with yet
WORKED EXAMPLE

Release one does not send client-facing email, does not integrate with the accounting system, and does not replace the month-end spreadsheet. Client email is revisited once weekly volume exceeds 50. Accounting integration is out until the finance system upgrade completes.

WHY THIS MATTERS HIGH

Ambition is not the problem, undiscussed ambition is. An unwritten exclusion is not an exclusion, it is a disagreement waiting for a deadline. Writing it down converts an argument that would have happened in month three into a decision made in week one, when it is cheap.

YOUR EXCLUSIONS Fillable in the PDF, four numbered rows
Seven-page worksheet plus guidance · 15 pages Read the rest of this page
Send me the worksheet
// WHAT IT COSTS

Fixed price per release, scoped in stages

We price a defined first release rather than an open-ended build. Later releases are scoped and priced once you have used the first one and know what you actually want next.

Get a written scope
WHAT MOVES THE NUMBER
How many distinct jobs the application has to do
How many systems it has to integrate with, and how cooperative their interfaces are
Whether it handles sensitive data, which raises the security and testing bar
Whether you need us to host and maintain it, or you are taking it in house
// FROM THE FILE

One of these, in the field

DECLASSIFIED

The spreadsheet that ran the roster, and the feature we talked them out of

A rostering spreadsheet only one person could edit, holding clinician availability and participant details. The build took nine weeks. The most useful thing we did was persuade them to leave a third of their wish list out of it.

Read the case file
// QUESTIONS, ANSWERED

Asked before signing anything

No. A runaway spreadsheet is the most common way this work starts, and the case study below is one, but the same team builds portals, integrations, reporting and automation. We also take on applications built by somebody who has since left, which is often the more urgent job because nobody currently dares change it. If you can describe the problem, we can tell you whether software is the answer.

Very often, yes. Custom software is worth it when the gap between what you can buy and what you actually do is where the value sits, or when the five-year total cost of ownership of the closest product genuinely exceeds the build. That comparison counts licensing, hosting, support, security maintenance and upgrades on both sides, not licence price against build cost. We work through it in the first session, and sometimes the answer is to buy.

See the buy-instead check in the build brief

You do. Source code and infrastructure are yours, and the documentation is deliberately written so another developer could take it forward.

That is agreed at scoping rather than left to launch week. Software needs looking after once it is live: dependency and security updates, hosting, and fixes when something it relies on changes. You can have us host and maintain it under a separate ongoing support arrangement, scoped and priced on its own, or take it to your own team or another developer, with the code, infrastructure and documentation already in your hands. Either way, a named person on your side owns the product.

Yes. It is done before launch by the same people who do our penetration testing, and it is in the release price.

Later releases get scoped and priced separately. What people want after three months of real use is usually different from what they would have specified up front, which is why we do not try to price it all at the beginning.

// OFTEN SCOPED TOGETHER

What usually comes with this

AI and Workflow Automation AI that does a real job, with the guardrails on AI and Workflow Automation, scope and pricing
Security Assessments and Penetration Testing Find it before someone less friendly does Security Assessments and Penetration Testing, scope and pricing

Tell us the problem, not the solution.

Get in touch
Shapes Shapes