Sam Halcrow

What I do

Let's get this exactly right the first time.

Three questions decide every software project: Is there a real outcome worth chasing? Do we know exactly what it is? Do we have the skill to reach it?

My job is making all three a yes before you spend real money.

Book introduction call

Some brands I've worked with

WestfieldElgasKasperskyDexionMYOBBoehringer Ingelheim
AccionaWestConnexAgilyxIsuzuTicked Off

You've heard or are experiencing the horror stories. They're mostly true.

Most software builds fail for one reason: distance. Distance between the people building the software and the business it's for. The people writing the code don't understand your business, and nobody on your side can tell whether the work is any good. Six months and a lot of money later, the thing doesn't work and nobody's accountable.

You don't actually own it

The vendor holds the code and the cloud accounts, and almost nothing is written down. Their rates go up every year. Moving to someone else means starting again from scratch, so you stay and keep paying.

The fixed price doesn't stay fixed

The quote was based on a spec written before anyone properly understood the problem. So everything you learn along the way gets treated as a change and gets a price attached. By month three you're negotiating with your own supplier instead of building anything.

It only works in the demo

In every meeting it looks nearly finished. Then you look underneath and there's no proper login security, nothing handles errors, and the database falls over with your first customer. That last stretch is where most of the real work sits, which is why a project can sit at 90% done for a year.

Nobody on your side can check the work

Someone non-technical signs off the build and the vendor marks its own homework. When they say it's nearly ready, you have no way of knowing. Every other problem on this list gets worse when this is the situation.

The app was the easy bit

You got a price for the app. You didn't get a price for connecting it to your finance system, your customer database, and the thing from 2009 that still runs the warehouse. Those connections often cost more than the app did. It's a mid-market problem, mostly, since startups have nothing to plug into yet.

Everyone's wishlist went into version one

Every department asked for something and it all got built. Eighteen months later nothing has been in front of a real user, and the assumptions it was scoped on have changed. It launches, and people just don't use it.

It all lives in one person's head

One contractor or one employee understands how the whole system works. When they leave, or come back asking for more money, you find out you don't own a system. You're paying for access to a person.

The pilot that never ships

Very common with AI projects at the moment. The proof of concept works beautifully, then it hits security review, or the data turns out to be a mess, or nobody worked out who was supposed to change how they do their job. It gets written up as a success and then sits there.

MY TRACK RECORD

Hear from the companies I'm currently working with

Angela Bevitt-Parr

National Marketing Manager
AWS Australia

Tim Buric

Chief Technology Officer
Agilyx & MUNIvers

Kelvin Kenney

Chief Executive Officer
Bow Wow Meow

How to start working with me

Three steps for a successful, stress-free software project

If we go ahead, you get a fractional CTO on your leadership team, and an engineering team behind me if you haven't got one of your own. You'll get the systems, skills, and structures a product company should run on, from day one.

Step 1

Book an introduction call with me

Bring the project, the quote, or the thing that's stuck. There's no prep needed and no pitch coming.

Book introduction call

Testimonials

This is what it's like to work with me

Step 2

I tell you how I'd lead and build this project

After the call, I send you a written plan: what to build first, what to leave out, what it should roughly cost, and what to look for in any quote already on your desk. Plain language, specific to your business, and yours to keep even if we never speak again.

Step 3

I lead and build it — or leave it with you

Take the plan to another builder if you like. Or we keep going together: with your team if you have one, or my team of 26 engineers if you don't.

Here's exactly what you get with me as your Fractional CTO.

Scope and decisions

I decide what's in and what's out, I lead the build, your team (or mine) writes the code. One person is accountable for all of it, and you're looking at him.

Core build

We build the smallest version that proves the business works. After that, every new feature has to earn its place against how people actually use it.

Usability and design

Software only counts if people actually use it. We design around how your customers and team really work, then test it with them. Good-looking matters. Getting used matters more.

Reliability and support

All software breaks eventually. When yours does, you ring someone who already knows how it's built. We monitor it, so we usually spot problems before your customers do — and a fix comes with an explanation.

Security and compliance

Security is built in from the first commit, not bolted on before launch. Access controls, encrypted data, and a record of who did what. When your biggest customer sends over their security questionnaire, you'll have the answers.

Scale and performance

Built to handle ten times the traffic you have today. We test it under real-world pressure before launch, so it's ready when growth comes.

Automation and AI

If a machine can do the job, we let it. Where AI actually helps, we use it — and where it's just fashion, I'll say so. Every automation has to save you hours or money, or it doesn't ship.

You own everything

The code, accounts, infrastructure, documentation — in your name from day one. If you ever want to take it elsewhere, you can, and nothing has to be untangled first.

Who I work with

We can work together if…

  • You’re an Australian company with 2-200 people
  • You need a software product built, and built to last
  • There’s no senior technical person in your leadership team
  • You’ve got a budget and want it spent like it’s precious

We shouldn't work together if…

  • You’re at the idea stage with no budget behind it
  • You’re shopping purely for the cheapest hourly rate
  • You want a team that says yes to everything
  • You’ve already decided exactly what to build and just want hands

FAQ

What I'm asked on most introduction calls

How do you price?

Day rates for embedded engineers and my fractional CTO time, or a scoped phase price where the work suits it.

Who owns the code and IP?

You do. Everything we build for you belongs to your business.

Can you take over an existing build or vendor situation?

Yes, a meaningful share of our engagements start as rescues or take-overs.

How quickly can you start?

Scoping within days. Engineering start is typically weeks and not months.

How long does a typical engagement last?

It varies. Some engagements are project-based with a clear end point. Others are ongoing because the company needs a permanent fractional CTO, not just someone to fix a specific problem. We work that out at the start based on what the company needs, and adjust as things change.

What kinds of problems are you typically brought in to fix?

It varies, but the most common situations are: a technology project that's drifted without a leader steering it, a business that's scaling and realises it needs technical leadership it doesn't have, or a founder who needs someone to take technical decisions off their plate.

My situation is more complex than these examples. Can you still help?

The engagements in these case studies range from straightforward to complicated: enterprise transformations, failing builds, businesses with no technical foundation at all. If you're not sure whether your situation fits, the easiest thing to do is get in touch and describe what's going on. Sam will give you a straight answer.

These companies look quite different from mine. Does that matter?

The industries vary, but the problems don't. Whether it's a logistics business, a pet insurance company, or a civil construction company, the issues that brought Sam in were almost always the same: no technical leader accountable for the outcome, engineers without proper direction, or technology decisions being made by the wrong people. The context changes, but the fix is usually the same.

Where are you based?

Sydney, working with clients across Australia.

What kinds of organisations do you typically work with?

Any organisation that is making significant technology decisions and needs someone senior enough to make them well. Some have engineering teams already, some don't. Some are mid-project, some are just starting. The common thread is they need a technical leader who's accountable for the outcome.

How is this different from hiring a full-time CTO?

You get the same level of judgment, experience, and accountability without the full-time salary, equity, or long-term commitment. It works particularly well for organisations that are about to start a significant technology project, need someone to lead an existing team, or want senior technical lead.

Do I get just a fractional CTO, or do I get a team of engineers?

You're primarily getting me as your fractional CTO, someone who's accountable for your technology. If there's building to do and you don't have engineers to do it, I can bring my own team. But that's an add-on, not a requirement.

Ready?

After our first meeting you'll leave knowing what to do next

Visit my office in Surry Hills

Exterior of a building with orange awnings and a sign above the door that reads “Prospect.”

Halcrow Office

116 Devonshire Street, Surry Hills NSW 2010

sam@halcrow.com.au

0431 197 004

Meet on a video call

Sam Halcrow on a video call

Book your introduction meeting with me

The most expensive mistakes in a software project happen before anyone writes code. This call is how you avoid them.