News

When you're building software, the instinct is to picture everything the system could eventually do — every edge case, every feature, every "what if" — and build for all of it from day one. It feels thorough. It feels like good planning.

It's usually the wrong move.

At Logical Developments, our experience over more than three decades has taught us the opposite lesson: start with the smallest thing that solves the real problem, get that right, and let everything else grow from a foundation that actually works. A sparse system that does the essential job correctly will always outlast an ambitious one that gets the fundamentals wrong.

Starting Small: ConNote

Years ago, one of our clients — a freight company — was running consignments through an old DOS-based system built for couriers, not general freight. It didn't fit the way they actually worked, and it showed.

We didn't try to replicate everything that system did, plus everything we imagined a "complete" freight platform should do. We stripped it back to the core job: enter a consignment, generate a manifest, generate an invoice — and enter each piece of information only once, linking everything back to that single source of truth.

That was it. That was the whole first version.

Because that sparse core was solid, everything else had somewhere stable to attach to. We added a price list function with home and away depots and rates between them. We rebuilt the technology on what's now our LD Modular Framework. We introduced a shared contacts module used across every customer. As we picked up more freight clients, we added custom layouts for each one, without disturbing the core.

What's now ConNote — one of our flagship products — didn't start as a grand vision. It started as three correct steps, taken one at a time.

Solving One Problem: Bookings

When that same client later pivoted out of freight and into truck driver training, they came to us with a different problem: a big A3 sheet of paper, tracking which trucks and trainers were booked against which student timeslots. It worked, in the way paper always sort of works, right up until two people tried to book the same truck at the same time.

We didn't build a general-purpose scheduling platform with every feature a booking system could conceivably need. We built Bookings, on our Modular Framework, to solve the one problem that actually mattered: when a booking was made, every screen needed to update immediately, so no two people could ever double-book the same resource.

Sparse, again — but correct exactly where it counted.

When It Goes the Other Way

Not every project in our history has gone this way, and it's worth being honest about that.

More than 25 years ago, we took on the job of upgrading a point-of-sale system we'd sold and distributed around Australia, moving it off an ageing database engine so it could run on modern operating systems. It was a reasonable idea to also modernise the system while we were in there — new engine, new capabilities, all at once.

It was a costly mistake. Taking on the platform upgrade and the modernisation together meant neither piece of work ever had a stable foundation to stand on. Behaviour was inconsistent from one build to the next, and we could never get the system to a state reliable enough to ship. Eventually, we abandoned the project.

It's an old story now, and the client and product aren't ones we'd name — but the lesson has stayed with us ever since: when you try to get two big, uncertain things right at the same time, you often end up getting neither of them right.

The Lesson

"Sparse" isn't a euphemism for unambitious. It's a discipline. Solve the real problem first, in the smallest correct form it can take, and prove that foundation before you build on it. Everything we've since added to ConNote and Bookings was only possible because the first version was small enough to get right.

Software that tries to be everything on day one usually ends up being nothing reliably. Software that starts sparse — and correct — has somewhere to grow.

Where Could This Start for You?

You don't need a full digital transformation plan to get started — you need one thing, sorted properly. If you've got a process that's held together with a spreadsheet, a paper sheet, or a system that was built for a job it no longer does, get in touch. We'll sit down with you, look at how your team actually works, and help you find that one thing worth fixing first — the sparse, correct starting point for your own road of continuous improvement.