Two jobs that get advertised as one
By the end of August a lot of owners are tired of invoices and tired of waiting. The thought is reasonable: put a developer on payroll, give them the backlog, stop paying workshop rates. Sometimes that is the right move. Sometimes it is how you hire a person to own a system nobody designed, with no one to review their work, and no handover when they leave in month eleven.
A product partner is a team that can carry a slice — process, data model, integration, deploy, the boring security list — and leave you able to run it. A payroll developer is a person who will be there on Tuesday. Those are different purchases. Mixing them is how you get a partner who never hands over, or an employee who is silently the vendor.
This is not a scorecard for choosing a company. That checklist already exists: how to choose a software development company. Use it when you are comparing proposals. This post is the prior question: should the next six months be a hire, a retain, or a short overlap of both.
When a payroll developer is the right hire
Hire when the work is mostly change on a system you already own. New reports, new fields, a second branch, a WhatsApp template, the kind of story that appears every week and should not need a statement of work. Hire when someone in the building can set priority and say no. Hire when you hold the source, the host, and the architecture notes — or you are willing to spend the first months making that true.
Hire when you can give that person a neighbour. One developer with no reviewer will invent a private framework. Two people, even if the second is part-time or a retained partner for review, is a different risk. A lone hire into a company that has never shipped software will spend a quarter discovering your GST exceptions and your Tally export. That can still be worth it. Price the quarter as learning, not as output.
Hire when the domain is yours and will stay yours. A dispatch process that is how you compete should not live only in a vendor’s head. An employee who sits with the night shift will see things a visiting team will miss. That is the actual case for payroll: proximity to the exception, not a cheaper hourly fantasy.
Do not hire first if you do not yet know the first slice. A person with no definition of done will build the system they have built before. You will fund that whether it fits or not. Write the slice. Then decide whether the person who builds it should sit on your books.
When a partner is the cheaper bench
Retain a partner when the next work is still a project: a first system of record, a migration, an integration you have not done, an AI feature that needs permissions and a log. That work needs more than one skill in the same fortnight — data, UI, host, a person who has seen Tally fail. One payroll hire will serialise that and call the delay “scope”.
Retain when you want a handover, not a hero. A good partner writes the assumptions, names the owner of exceptions, and leaves source and a way to change a rate. A weak partner becomes a second payroll you cannot manage. The choose-a-company guide is how you tell them apart. The point here is that “we should just hire” is not an escape from that judgement. You will still need it, only now as an interviewer with a salary attached.
Retain when the load is lumpy. Four quiet weeks and then a GST-shaped emergency is a bad year for a single employee and a fine year for a team you call when the slice is real. Paying for idle months on payroll to avoid a partner’s rate is a spreadsheet that ignores the months you will still be stuck.
Consulting that ends with a written picture of the system — what is source of record, what is a sheet, what to build next — is IT systems consulting. Building the .NET slice is .NET development. Those can be the same firm. They should still be named as two jobs so you know when you are paying for thinking versus shipping.
Handover is not a zip file
Whether you hire or retain, the test is the same: can a third person change a rate next quarter. Source in a repo you control. Host and registrar on company accounts. A one-page architecture: where production lives, how you deploy, where backups are, which system is allowed to invent an order number. Secrets not in a personal password manager. A restore you have watched.
A zip on email is a souvenir. A repo the vendor owns is a lease. An employee who will only work from a copy on their laptop is a vendor with PF. Put the work on your organisation’s git and host from the first week, even if a partner is writing every commit. If they will not, you already know the answer to “who owns this if someone leaves”.
Documentation that matters is the exception path, not a generated API list. What happens when the supplier is new. Which field finance will not forgive if it is wrong. How to undo a dispatch. The person who leaves — staff or partner — will take the hallway version of that. Write the hallway version down while they are still in the hallway.
Training is not a PDF in a shared drive. It is the packing supervisor completing the job without you. If only the developer can close the month, you hired a bottleneck. That is true on payroll and on a retain. Fix it before you celebrate go-live.
Who owns architecture if someone leaves
Architecture is the set of decisions that are expensive to reverse: the system of record, the identity model, the integration style, where files live, what is allowed to call the bank. If those decisions live in one head, you do not have an architecture. You have a person.
On payroll, ownership should be written: this person decides the data model; this manager can overrule on process; a reviewer exists for the decisions that lock you in. When the person resigns, you are buying time and notes, not a new product. If you cannot point to the notes, start writing them this week — before you need them.
With a partner, ownership should be written in the agreement: you own the source; they own the quality of the slice they shipped; a named week after go-live; a path to ask questions that is not a new project unless it is. If the partner’s architect is the only one who understands the Tally connector, you have the same bus factor as a lone hire. Demand a diagram and a second person who has deployed it.
Students and intern-heavy benches can ship a demo. They struggle when item codes collide or the night shift refuses the screen. That is true of a cheap hire and a cheap vendor. Ask who was still there after go-live on a job that looked like yours. Adjacent work is fine. Unrelated landing pages are not evidence that someone can own your billing exceptions.
The hybrid that actually works
The grown-up pattern for a firm that is growing into software is overlap. A partner ships the first slice and the integrations. A hire joins in time to sit through the parallel run, take the repo, and own the weekly change. The partner stays for a review hour and the next hard integration. You stop paying build rates for work the hire can now do. You do not fire the partner the Friday before go-live and hope.
The failure pattern is the opposite: hire first into a green field, then call a partner when the data model cannot accept a second branch. You will pay for a rewrite and for a salary. If you are early, buy the slice. Hire when there is a system to tend.
Another failure: keep a partner forever for work that is now a field change, because nobody hired the neighbour. That is comfort, not strategy. If the backlog is truly weekly and small, do the hire. Keep a small review retainer if you have only one person. Review is cheaper than a quiet rewrite in a private branch.
What you should not outsource, and what you should not hire first
Do not outsource the exception owner. The person who knows what “wrong GST” means has to be yours. Do not outsource the priority. A partner who sets your roadmap without a voice in the building will build a beautiful backlog for a company they invented.
Do not hire a “full stack ninja” as your first employee because a job board said so. Hire someone who has shipped a line-of-business system and can talk to finance without translating. If you cannot interview for that, pay a partner to sit in the interview. That hour is cheaper than a year of a brave mismatch.
Do not hire a CIO title when you needed a person who will look at the backup log. Titles are how small firms postpone the boring list. Do not retain a partner only as a body shop under your daily stand-up if you cannot manage software. You will get the worst of both: their rate, your chaos, nobody owning architecture.
A six-month test
If you hire, the six-month test is: source on your org, a second person who has deployed, a change the business asked for that did not need the original author, and a restore that was not theoretical. If those are missing, you have a person-shaped risk. Extend probation in facts, not in hope.
If you retain, the six-month test is: you can run the system for a month without them, you hold the keys, the next slice is written, and you know whether you still need a team or a hire. If you cannot run a month, you did not buy a partner. You bought a dependency. Fix the handover before you buy the next module.
If you do both, the test is whether the hire can explain the architecture the partner left, in their own words, to you. If they can only say “it is in the repo”, the overlap failed. Sit them together for the Tally path and the undo path before you let the partner’s last week expire.
None of this needs a rupee comparison in a blog post. Salaries and retainers move. What does not move is the bus factor, the source, and the named owner of the next exception. Make those three explicit and the hire-versus-retain argument gets shorter. If they stay implicit, you will have the argument again in March, with a resignation letter on the table.
When you are ready to compare firms, use the choose-a-company guide and a one-page brief. When you are ready to compare a salary to a retain, use this page and the handover test. Do not use either page to postpone writing the first slice. Without a slice, both a hire and a partner will invent one for you — and you will still own the result.