Solve the problem, then leave
The work ends when the problem is solved.
Companies still get sold a small prototype, and then a conversation about the real project. The prototype is something to throw away. The conversation is a promise that the serious work starts later. The problem stays where it was.
The hire is smaller than that split, and it is finished. Take a process the team already runs. Write how it works today. Build the fix on the real records. Hand back the code and a plan that says the monthly cost, where the data sits, and what breaks off the sample. Then leave.
What finished work covers
Finished work covers the center of the problem. The center, and the cases that show up every week.
If the job is reading contracts, it reads the contracts the team already has. If the job is keeping an order the same in the ERP and the CRM, the two systems show the same record. If the job is an internal assistant, it answers the questions people already ask, and it says so when the file does not contain the answer.
Real records
A clean sample spreadsheet makes almost any design look finished. Missing fields, bad PDFs, and rules nobody wrote down show up when the fix runs on the records the team already uses.
A bar, written down before the code
Someone says what good enough means before the build starts. One manual step gone. A minimum accuracy. A sync that does not write a second row. A person who can finish the task without a developer in the room.
What still gets sold in place of the work
Slides help a meeting. They do not run on Monday.
A requirements document describes intent. It does not show the job on the real records.
A demo on perfect data answers the easy case. The hard case is the file the team already has.
A pilot that needs a second contract before it touches the systems in use is a prototype with a calendar. The problem is still open when that contract ends.
Where the split gets expensive
The cost of the wrong software rarely shows up in week one. It shows up after the team has spent time, attention, and budget.
One company approves six months for an internal portal with automation and AI. Ten weeks in, the data are incomplete and half the scope was never the priority.
Another company spends three weeks on the risky center, on the real records, and stops when that center runs. There is no second phase waiting. The code is already theirs.
The second path still has risk. The risk is paid inside the work, not saved for a later conversation.
What to ask before you hire
- Will this run on the records we already have?
- Do we keep the code when you leave?
- Is there a second phase, a pilot, or a prototype you expect to throw away?
- What is still unfinished on the day you leave?
- Where does the monthly cost come from, and what breaks off the sample?
Vague answers mean the problem is still yours, and the next meeting is the product.
The bottom line
Send the process the team already runs. You get a write-up of how the work happens today, the fix on your data, and a plan to keep it running. The problem is solved. The code is yours. Then we leave.
See also: