Most people hear “AI engineer” and picture something enormous. A startup built in a garage. Somebody in a hoodie typing lines nobody else can read. Something far away from the Tuesday you are actually having.
The real work is smaller than that picture and a lot more useful. It is the plumbing nobody notices until it stops.
We do all of it on SuperCool — our own platform — one login and one agent, because we have watched the other way go wrong. Anything that makes you connect this and connect that, then wire up an MCP and hand-write a five-step prompt before it does a single useful thing, gets abandoned by week two. Nobody wants a million logins, and nobody wants to be the plumbing.
This is the list as people actually bring it to us, with what each job looks like on a normal week.
The jobs people actually bring them
Make two systems that were never built to talk, talk
Your customer records live in one place and your invoicing lives in another. Your booking tool and your spreadsheet have never been properly introduced. An order lands on the website, and somebody retypes it into the system that actually ships it. On a normal Tuesday that is ninety minutes of copying between two screens, and two of those copies are wrong. Joining them is a job somebody does once. After that the order creates the invoice, updates the customer and tells whoever packs the box. There is nothing clever in it, and it is the bridge nobody ever built.
Replace the spreadsheet four people fight over every Friday
Almost every business has one. It gets called master list, or bookings final v3. Everybody edits it. Two people edit it wrongly. On Friday morning somebody sorts it by the wrong column and it stops agreeing with the invoice system. That sheet is the company's real database wearing a costume, and it has no permissions, no history and no rules. An engineer turns it into a proper tool: one place to enter the thing, the right fields on it, and a version two people can work in without losing each other's notes. The Friday argument goes away because there is nothing left to argue about.
Rescue the automation that quietly died three months ago
Somebody set up a flow last year. Invoices to the bookkeeper. New leads into the customer list. Low-stock alerts to the warehouse. It worked for a while. Then a login changed or a form field moved, and it stopped, and nobody heard anything because it had always worked quietly in the background. Things have been leaking ever since, most of it invisible. The job starts with working out what should be running and what actually is, which is the part nobody does because nobody keeps the list. Then it gets fixed, and it gets an alert attached, so the next failure reaches you in an hour rather than in a year.
Build the small internal tool nobody sells
Off-the-shelf software stops at about eighty per cent, and the missing twenty is usually the piece you bought it for. Your quotes need a discount rule the product does not have. A job cannot be marked complete without three photos and the tool only takes one. The scheduling app almost fits, apart from the way your two-person crews pair up. There is no product for that, because there are not enough businesses like yours. It is a week of work for somebody who knows what they are building, and it decides whether your team uses the software happily or quietly works around it.
Clean up the data nobody trusts
If the same customer appears three times with three spellings, every number built on top of that list is a guess. So is every email, because a third of it goes to a version nobody opens. Somebody pasted over the phone numbers during an import two years ago and it has been wrong ever since. The pipeline says forty deals and you know it is closer to twelve. Cleaning this is not glamorous. It is de-duplicating, fixing the formatting, deleting the dead rows, and putting a rule at the door so the mess stops coming back in. A few days of it makes the reports you already own worth reading again.
Build the dashboard that answers the one question you ask every morning
You do not need forty charts. You need one number before coffee. Booked jobs this week. Invoices past thirty days. Quotes out, quotes signed. Right now that gets answered by asking somebody in the office, who asks somebody else, and the answer reaches you on Thursday. The dashboard reads from systems that are already running and shows you that number, updating itself as the day goes on. The second one gets added the week you work out what the second one is. Because it lives in the same login as everything else, checking it is one tab instead of four.
Watch the thing that breaks at two in the morning
Systems fail at bad hours. A payment provider changes something on a Sunday. A certificate expires. An integration starts returning errors and your store quietly stops taking orders while you are asleep. None of that is visible from the sofa. Somebody sets up monitoring so the thing tells a person the moment it goes wrong, and, where it makes sense, repairs itself: the retry happens on its own, the failed job gets re-sent, and one line arrives telling you what happened. You still find out. You find out at breakfast, before a customer has to tell you.
Know when to hand off to a real developer, and say so
Some builds are genuinely big. A marketplace with two sides. A payments system with rules attached. A replacement for the platform the whole company runs on. Honest people say that in the first conversation rather than in month three. What you want is a clear line: what one person can hold safely, and what needs a team with a spec and a deadline. Everything before the line is fast and cheap. Crossing it is fine, and it should be a decision you make with your eyes open rather than the thing you discover six weeks in.
What they don’t do
An engineer does not invent your strategy. Nobody builds their way to a business model. If you have not decided which customers you want or what you charge them, that comes first, and it is your call. What you get is a straight answer about what is possible and what it would cost, including the answer that the sensible move is to do less.
They are also not a deep specialist on a genuinely hard build. Difficult engineering needs somebody who does that narrow thing every day. One generalist pointed at everything is how a two-week job turns into six months. The useful version is an early, plain split: this part is mine, and that part needs somebody else.
What everyone asks
These come up every single time. Do I need to hire a developer as well, and who owns what gets built when we are done? Is this one more login to keep track of, and what happens when it breaks? How long until it is actually working, do you need access to everything, and what if my situation is weird and does not fit the template?
All fair questions. Underneath them there is usually one that never gets said out loud.
What we won’t tell you
Anyone who says yes before looking at your setup is guessing. Building is the easiest thing in the world to promise.
The honest version sounds duller. Let me see the mess first, and then I will tell you what it takes and where it could go wrong.
A good engineer’s first move is a dull question, not a grand plan.
Why this is not the same as hiring a developer
The two roles sound alike and behave differently, especially after the invoice clears.
Wants a spec, builds to it, hands it back, and moves on to the next project.
Starts by asking what it needs to do, stays until it is stable, and writes down how it runs.
What a first month looks like
- Week one: the look around
What does this need to do, what do you already pay for, and what is the smallest version that gets you there.
- Week two: the first thing works
The connection, the tool or the automation goes live and you are using it on real work.
- Week three: the edges
The mess nobody mentioned out loud. Duplicate records, an import everyone is afraid to touch, a process only one person knows.
- Week four: the handover
Notes, a diagram and a walkthrough, so the thing stops being a black box and starts being yours.
That is the job list. It is not what a startup founder does, and it is not as exciting as the job title suggests. It is the pile of work you have been doing by hand, done properly, written down, and owned by someone who stays until it works.
How long until it is actually working?
Most first builds are live in about two weeks, and a few are finished in a day. The setup decides it — how many systems are involved, and how much of the data is a mess. Which matters less than the part that follows: whether the thing is still running in three months without anyone babysitting it.
Do I need to hire a developer as well?
No. Getting one specific thing working, and keeping it working, is the job. If a project genuinely needs a software team, that is worth saying at the start rather than selling you a build that will not hold. Either way you find out before you spend money on a team you may not need.
Who owns what gets built?
You do. The tool, the connections and the automations belong to you and go with you. The reason it matters is simple: a business that owns its systems can change them without asking anyone’s permission first.
Do you need access to everything?
Only what a specific job needs, and you approve each one before it is connected. Access gets removed when the work is done. What that buys you is a build with nobody permanently sitting in your accounts.
What happens when it breaks at nine at night?
You send it in and it gets picked up when your specialist is on. Nothing gets dropped. And because the person who built it is still around, the fix comes from someone who already knows the shape of your setup, which is usually faster than starting a hunt from scratch.
What if my situation is weird and does not fit the template?
Weird situations are most of the work. Two systems nobody has ever connected, a process that only makes sense to the person who invented it, a spreadsheet held together by habit. That is the material, and it is where a build is worth doing at all.
Does this mean one more login?
Usually fewer. The point of joining two tools is that you stop hopping between them, and an internal tool lives in the same place as everything else you run. Fewer places to check means fewer things to forget.
Can you fix an automation somebody else built?
Often, yes, and it is a common request. The first step is working out what it was supposed to do and whether it ever did it properly. Sometimes the fix takes five minutes, and sometimes the honest answer is that rebuilding it is cheaper than repairing it. You hear that before any work starts.
How much will this cost me in credits?
Building software uses more credits than images or video, and a professional spends fewer of them than you would, because they know what they are doing. The number that matters is the hours you stop paying for once the thing runs on its own.
