Tech
AI can write the code. Your business still needs an engineer.
Tomislav Simnett
11 min read
You probably don’t need a CRM.
You need a more profitable business.
That might sound like I’m being deliberately provocative, particularly given that we build bespoke CRMs, applications and business systems for a living. But it gets to something I think businesses are going to have to understand as AI gets better at building software.
The software isn’t the objective.
Neither is the CRM. Nor the app, the automation, the AI integration, the RFID system or the shiny new dashboard.
They’re all possible solutions to something else.
So before we start talking about what to build, there’s a much more important question:
What are you actually trying to make better?
That has always mattered. Now that AI can write increasingly good software, it matters even more.
AI really can build software
There’s no point pretending otherwise.
Give today’s AI coding tools a reasonably clear description of an application and they can build an extraordinary amount of it. Screens, databases, integrations, business logic, tests, APIs. The speed at which a competent person can now turn an idea into working software is remarkable.
We use AI to write software too.
And, increasingly, I think it can write plenty of the code as well as I can, sometimes better.
But that doesn’t worry me particularly much, because the code was never the thing that made a great product great.
The difficult bit happens before that.
It’s understanding what should be built.
More importantly, it’s understanding whether the thing somebody has asked you to build should exist at all.
That distinction gets lost very easily when we talk about vibe coding. A business owner can now sit down with an AI app builder and say, “Build me a CRM that does this, this and this.”
And it probably will.
But there’s an assumption hidden inside that prompt.
You’ve already decided you need a CRM.
Who decided that?
Why?
What is actually happening in the business that led you to that conclusion?
Maybe the answer really is a CRM. But I’d rather discover that than start by assuming it.
A quote isn't really a quote
Take something as ordinary as producing a quote. A business might tell me that its quotes take too long, and it would be very easy to accept that as the problem. We could look at the existing process, pre-fill some fields, connect the CRM to the quoting system, perhaps use AI to write some of the content, and turn a 30-minute task into a five-minute one.
That might be useful. But I still don't know whether we've solved the right problem. Why does it take 30 minutes? What is somebody actually doing during that time? Who decided 30 minutes was too long? And, once you follow that line of questioning far enough, there is a more fundamental question.
Why does producing a quote take any time at all?
The PDF isn't really the quote. It is a representation of information the business has learned. The customer wants something, in a particular quantity and specification, perhaps with options, at a location and by a certain date. There are costs and commercial rules that determine what the business is prepared to charge. Some of that information comes from the customer, some of it already exists in the business, and some of it may require judgement.
As those facts become known, the price becomes knowable too. So why do we treat "making the quote" as a separate activity that happens afterwards? If the information is sufficient to calculate the price, calculate it. If an unusual margin needs approval, ask for the approval at that point. If somebody genuinely needs to exercise judgement, put the human exactly where the judgement is needed rather than making them perform the rest of the process as well.
That is a very different exercise from making the existing quoting process faster. One digitises the process we already have. The other asks whether the process still makes sense once the system understands the information moving through it. And the quote is only the beginning.
The business has learned something. Now what?
The customer accepts the price. At that moment, the business has learned something else: the job is going ahead. In plenty of organisations, that starts another chain of administration. Somebody creates a job in another system, somebody checks when it can happen, somebody works out who has the right skills, materials are checked, a vehicle is chosen, the address gets copied somewhere else, instructions go to another team, a spreadsheet changes and a diary changes.
Look closely at those steps and most of them are not creating much new information. They are moving information the business already has from one person or system to another. We think of them as separate tasks because separate people have historically performed them, but that doesn't mean they need to remain separate tasks.
If the business knows what has been sold, it may also be able to know what type of work is required, what skills are needed, which people have those skills, what materials or equipment are involved, where the customer is and when the work needs to happen. If availability, vehicle capacity and existing commitments are also known, the system has enough context to carry the work much further than simply producing a PDF.
That doesn't mean handing every decision to software. Some jobs will be odd. Some constraints will not be in the data. An experienced scheduler may look at tomorrow and know immediately that the technically optimal answer is a terrible idea. Good. That's judgement, and it is valuable. The engineering question is whether that person needs to touch every job in order to apply it when it matters.
The point isn't to remove people. It is to stop wasting them.
That is the difference between automating a task and engineering the work around it. Automation starts with the task and asks how to make it quicker. Engineering is prepared to step further back and ask:
Why is this a task in the first place?
Sometimes there is a very good answer. Sometimes the task exists because information doesn't move properly through the business. And sometimes, once you understand what the task is really doing, you can remove it altogether rather than automate it.
The problem with vibe coding isn't the coding
This is why I think some of the discussion around vibe coding starts in the wrong place. There are real technical risks in asking AI to build important business software. Security, data, architecture, testing and maintainability all matter. But those are familiar engineering problems. They can be reviewed, tested and improved.
The more interesting risk is that AI makes it remarkably easy to build exactly the thing you asked for. Your prompt contains your assumptions. If you believe your salespeople need to create quotes, you'll ask for a better quote builder. If you think you need a CRM, you'll describe a CRM. If you've already decided warehouse staff need to scan stock, you'll ask for a scanning workflow.
AI can challenge those assumptions. I use it to challenge mine all the time. But it can only work with the reality that reaches it. If the description of the business is incomplete, the reasoning starts from an incomplete picture, and in real businesses a lot of the important picture is not sitting neatly in a process document.
There might be a spreadsheet sitting outside the "official" process. Nobody put it in the specification, but somebody created it for a reason. What does it contain that the proper system doesn't? What breaks if somebody stops updating it? There might be a Post-it beside a monitor because one piece of information never appears where somebody actually needs it. Two people may have learned to speak to each other before a particular step because something goes wrong if they don't.
Then there is the knowledge that is harder to point at. An experienced employee can look at a job and know who should do it. If you ask them for the rule, they may not have one. So I want to know what they noticed. Was it the customer, the location, the specification, the combination of work involved, or something they only recognise because they've seen a hundred similar jobs before?
Ask somebody to describe a process and you may get the process as they understand it, or the process as it is supposed to work. Stand beside them while they do it and you start seeing the exceptions, the shortcuts and the moments where the official process stops matching reality. That gap is often where the most important requirements are hiding.
So I don't think good software engineering can be reduced to sitting in a meeting room and asking managers what features they would like. You have to get close enough to the work to understand why people behave the way they do before you decide what the software should make them do differently.
Sometimes the best technology really is a Sharpie
Imagine we're looking at a warehouse and somebody tells us they need a better way of identifying individual units of stock. It would be easy for the conversation to become technical straight away: barcodes, QR codes, RFID tags, handheld scanners, phones, integrations with the stock system. They are all reasonable options, but I don't want to choose between them yet.
I want to stand next to the person doing the job. Perhaps they're wearing gloves and already have something in one hand. Maybe they're moving quickly, a pallet is in the way and somebody else is waiting to get past. The scanner may only be a few metres away, but a few metres matters when you repeat the same movement all day.
Then you notice that the person already writes something on the box with a Sharpie. That is where the interesting questions start. What does the mark mean? Who needs it next? Why does this particular unit need identifying? Does the system already know enough to infer the answer? If the Sharpie takes two seconds, what exactly would we improve by replacing it with a scanner?
RFID may still be the right answer. The point is that we don't know that until we understand what is actually happening. Sometimes the best engineering decision is to introduce sophisticated technology. Sometimes it is to leave the Sharpie where it is because the alternative adds cost and friction without improving the work.
This is also where I think we need to be precise about what AI can and cannot do. If I describe that warehouse in enough detail, AI can reason about the scenario extremely well. It can think about ergonomics, scan distance, interruptions, error rates, stock movements and things I may not have considered. That makes it an excellent partner in the design process.
What it cannot independently supply is the observation I never made. It cannot notice the hesitation I failed to describe, walk the route I never mentioned or feel that taking a glove off fifty times a day is far more irritating than it sounds in a specification.
As a human being, I can also try to put myself into the worker's situation. Not perfectly, and not instead of asking them, but enough to ask better questions. What would I remember when I'm rushed? What would annoy me after the fiftieth repetition? Why does this workaround make sense from where they are standing, even if it looks inefficient from an office?
That matters because the click, scan or button press is not the product. It is just one tiny moment inside somebody's working day. If you only design the interaction and not the reality around it, you can build something technically impressive that makes the job worse.
A good developer is not necessarily an engineer
This is probably the part that will irritate a few software developers, but I think a lot of developers are shocking at this. I don't mean they are bad programmers. Some are exceptional programmers, and if you give them a well-defined requirement they will turn it into clean, reliable, beautifully structured software.
The problem is that a lot of software development work begins after the requirement has already been accepted. If the requirement says there should be twelve fields and a button, the job becomes building twelve fields and a button well. If the specification asks for a quoting module, the job is to build the quoting module. If the customer says RFID, the technical conversation starts with RFID.
An engineer has to be willing to reopen the question. Why are there twelve fields? Where does the information come from? Does the person filling them in actually know the answers, or does the business already know them somewhere else? What happens when the button is pressed, and why does a button need pressing at all? What happened immediately before this screen appeared, and what needs to happen afterwards?
Those questions are not really about Ruby, JavaScript, Python or whichever framework happens to be fashionable this year. They are about systems, people, behaviour, information and consequences. The programming language matters when we build the thing, but it doesn't tell us what the thing ought to be.
That, to me, is the engineer bit.
An engineer should be prepared to challenge the thing they've been asked to build, look at the whole system rather than optimise one small part of it, and recognise when an elegant technical solution is making the human job worse. Sometimes better engineering means adding software. Sometimes it means removing a step, joining two pieces of information together or deciding not to build something at all.
AI makes that judgement more valuable, not less. If implementation becomes dramatically cheaper, then implementing a bad idea becomes cheaper too. The expensive mistake is no longer necessarily writing the code badly. It can be confidently encoding the wrong understanding of the business.
Should you vibe code your own app?
Sometimes, absolutely. If you've got an idea for a small internal tool, you want to test a hypothesis or you need something that helps you personally do a job, try it. The ability to create working software in hours without assembling a traditional development project is brilliant, and businesses should take advantage of that.
I become much more cautious when the software starts changing how the organisation itself works. If it determines prices, allocates jobs, controls stock, passes work between teams, handles important customer data, triggers financial processes or becomes something people depend on every day, you are no longer just experimenting with an app. You are encoding part of the business.
A required field becomes something somebody has to know or find. A button becomes an action somebody has to remember to take. An automated decision changes what somebody else sees or does next. If the model of the business is wrong, people then start creating workarounds around the software, and those workarounds become part of the real process whether you intended them to or not.
People will often adapt themselves to a poor system because the work still has to get done. That can make bad software look more successful than it is. The process still moves, but only because people are carrying the gaps themselves.
So the useful question isn't simply whether AI is capable of writing your business software. Increasingly, it is. The question is whether you understand the business well enough to decide what the software should be allowed to change.
This is what you're really buying from Initforthe
At Initforthe, we build bespoke CRMs, internal applications, integrations, automation and AI-enabled systems. But I don't particularly want you to come to us because you've already decided which one of those you need. Come to us because something in the business isn't working as well as you think it should.
Maybe revenue is growing but headcount seems to have to grow with it. I don't want to jump straight to automation; I want to know why. What are the extra people doing? Which part of the workload actually grows with each new customer? If everybody is flat out, what are they flat out doing, and which of those things should a person be doing at all? If customers are waiting, where are they waiting and what information or decision are they waiting for?
Perhaps nothing is obviously broken. You may simply have the sense that a business with good people, good customers and decent technology ought to be capable of more than it is currently producing. That is still worth investigating, because hidden friction does not have to look like a crisis. It can look like another hire, another spreadsheet, another weekly meeting or another person who has become indispensable because too much of the process lives in their head.
Our job is to get underneath that. We observe how the work actually happens, follow the information as it moves through the organisation, understand why the workarounds exist and work out where human judgement genuinely adds value. Then we can decide what the technology should do, what it should make easier and what it should leave alone.
Sometimes the answer is a CRM. Sometimes it is automation or AI. Sometimes it means joining together systems you already have. Sometimes it is a bespoke application that does not fit neatly into any software category. And occasionally the best answer is that you should not build something at all.
That is why I don't think AI replaces what a good software engineer brings to a business. It changes which part of the job is valuable. Writing the code is becoming easier.
Knowing what should exist is not.
Ultimately, you're not buying software from us. You're trying to build a more effective, less stressful and more profitable business.
The code is just how we make that real.
How much capacity is your business leaving behind?
Use the calculator to estimate what slow processes, manual work and disconnected systems could really be costing you.
More posts.
View all
Business
Four interruptions, two lost hours and the process your people shouldn’t be driving
Four interruptions can wipe nearly two hours from the useful part of a working day, and that’s before you count the interruption itself. Add long manual processes, routine human error, rework and stress, and you get a working environment where good people spend too much time recovering, correcting and chasing.
The answer isn’t to tell people to focus harder. It’s to design a better system, one that drives the process, preserves context, moves routine work automatically and only interrupts people when their judgement is genuinely needed.
Tomislav Simnett
10 min read
Business
The approval takes five minutes. The waiting costs far more.
A five-minute approval can leave work waiting for days. Once a quote, purchase, job or invoice misses its slot, the delay spreads into the rest of the process.
People switch tasks, schedules move, customers wait and cash arrives later. The decision itself may be quick, but the queue around it can cost far more than anyone realises.
Tomislav Simnett
9 min read
Business
You probably don’t need a CRM; you need the work to flow properly.
Most growing businesses think they need a CRM, but the real problem usually sits between departments.
When sales, operations and finance all rely on different systems, spreadsheets and good people end up holding the process together by hand.
When sales, operations and finance all rely on different systems, spreadsheets and good people end up holding the process together by hand.
Tomislav Simnett
6 min read