It is a small job. Is a freelancer not enough?

A freelancer is enough when the job has few moving parts, and one person can be the right answer for you. Çatalca Merkez Kasap is one menu page: nothing behind it takes orders or holds stock, changing a price means editing the text, and nobody reprints the code on the table. The document to ask for is the handover list, so you can stand the page up again under your own account. Have it written before you sign.

Our freelancer stopped answering. The system is ours, but nobody can touch it. What do we do?

It gets taken over, and reading the code comes before writing any. KGM SsangYong had a corporate site already serving visitors when the work came to us: the code was read first, the parts that worked stayed where they were, and changes went only where the pages were heavy. Your system follows the same order, so first tell apart what is recorded from what sits in one person's memory. We draw the boundary of a takeover in the first conversation.

Won't an agency tie us to itself just the same?

It will, and that arrangement does not suit every business: when the author of a system also maintains it, you depend on the author. AlgoKlima's field app and office panel share the same record, so a new field on it moves both surfaces, and the team that wrote it knows where without looking. The tie costs you on the day that team is unavailable. Run the table on an agency too; what you test does not change.

How do we run acceptance?

You run it according to who enters the information. If one person enters it and no other role ever opens the screen, a walkthrough is enough and the signature can follow. If two roles touch the same information, acceptance becomes a scenario. AlgoKlima's scenario has a technician, with no signal, adding a note to a service record while the office edits another field of it from the panel; one record left when the connection returns means it passed. The role doing the work picks the scenario.

An agency wrote this page. Isn't it going to recommend an agency?

It does not: the row where one person is the right answer is written out, and every row applies to us. We give no headcount, because a number cannot be checked; capacity here comes from a development partnership, and shared work is marked on the project page under the partner's name. AlgoCar is ours to run and keep developing, and the chain from a work order to an invoice stays on our own maintenance calendar. Put the same two questions to us, in writing.

Freelancer or software agency: two questions for both

Freelancer or software agency is a question you settle by putting the same two to both candidates: who maintains the system after launch, and whether you could rebuild it without the person who wrote it. The category does not decide; your own work does. AlgoCar takes a part out of stock as soon as a work order records it, and a chain like that needs a maintainer named in writing.

Two quotes are on your desk, one from a freelancer and one from an agency. The prices differ; what you would be buying with each is written in neither. This page sets the category aside and asks two things instead. Who owns the system after it goes live? And could you rebuild it yourself on the day the person or team behind it stops answering? You put both to both candidates.

Why these two questions

There are three real answers to the maintenance question: the side that wrote the system keeps it, another side takes it over, or your own staff does. None of the three belongs to a category. One person can be the author and so can an agency; either way the knowledge stays with whoever wrote the code, and it ties you to them. How that choice gets made, and what it then governs, is the subject of who maintains software after launch.

What decides the weight is not how large the system is but how much follows on its own from a single movement. So neither of the two sections below tells you what a freelancer does. They tell you which side your own work sits on.

The job where one person is the right answer

A job with few moving parts keeps the maintenance question light. If the content rarely changes, there is nothing behind it to refresh, no pair of edits to reconcile, no second movement set off by the first. One person is the right answer there, and the table on this page leaves that row filled in.

The menu page of Çatalca Merkez Kasap is the smallest job in our portfolio. Whoever opens the menu is sitting at a table with their own phone and decides within seconds; the page loads once, and a price change leaves the printed code on the table untouched. Nothing behind it takes an order, a payment or a count of stock. The maintenance question is light here: one page, one text, one edit.

Both questions still get asked, and the answers are short. Who edits the text when a price changes, and can you open the page again under your own account if that person is unreachable? Acceptance is short too, because one person enters the content and no other role opens it. That a walkthrough is the acceptance in a job this size is stated in what to test before accepting software, and the items of the document you ask for are counted in what you should receive at software handover.

The job where a team is the right answer

The question gains weight once one movement starts setting off others. In AlgoCar a part written to a work order leaves stock at that moment and the invoice line comes from the same row; the chain closes inside one system. When a new field enters that chain, the question is not how the screen looks but which link the value is read from. The side that does not rediscover the answer each time is the side that built the chain.

AlgoKlima carries the same weight across two surfaces. A technician opens a service record where the signal ends, the record waits on the phone, and it reaches the office panel when the connection comes back; edits made in the field and in the office merge into one record. Add a field and both the queue on the phone and the screen in the panel have to move with it, and that link is usually not written down anywhere.

The counter-row needs writing too. A team ties you to itself as well, and on the day it is unavailable you hold a system you have never read. So you put to the team what you put to the single person: is the handover list written before signing, and which difficult day did the acceptance scenario come from? Where two roles touch the same information, acceptance does not close on a tour of the screens.

What agency means here

An agency wrote this page, so the word needs explaining before the table is handed over. Our capacity grows through partnership rather than headcount: part of the work runs with a development partner, responsibility for that part stays with the partner, and the split is marked on the project page under the partner’s name. We give no headcount, because the headcount row says you could not check it. The checkable version is reading who the work was done with off the project page, which is how questions to ask a software company frames it.

Continuity comes from our own products. AlgoKlima and AlgoCar are live and still being developed, and their version upgrades and support load sit with us. AlgoRandevu, Secretum and QRVizit are not live yet, and their project pages do not pretend otherwise. We pay the maintenance line in our own products before writing it into a quote, so that is where you read our answer to the maintenance row.

The table below builds both columns in the language of testing: what you test when working with one person, and what you test when working with an agency. No cell describes the other side; every cell is a step you take. Run it on both candidates, then on us. Write into the quote form, in one sentence, what follows on its own from a single movement in your work, then read the reply for both answers. If you hold a system one person wrote and nobody now looks after, the boundary of a takeover is written on the software consulting page.

Side by side

Criterion	What you test when working with one person	What you test when working with an agency
Where the work continues when the builder stops answering	The answer is one name. Since there is no second one, ask for the handover list and the setup instructions in writing before you sign.	The answer is a team name. Ask which person answers, and whether the part done with a partner is marked on the project page.
What the maintainer has to know	If the author maintains it, nothing has to be read first; since the knowledge sits in one head, ask for a map of it that lives outside the code.	If the maintaining team did not write it, it reads before it acts; expect the map from the handover list, not from a conversation.
The moving parts in your work	Content that rarely changes has nothing behind it to refresh and no pair of edits to reconcile; one person is enough.	Where one movement sets off others, test whether the maintaining team knows that link.
The shape of acceptance	If one person enters the information and no other role ever opens the screen, walking through the screens is the acceptance.	If more than one role touches the same information, acceptance is the scenario where the second person opens it; sign on the final state.
What replaces the headcount question	Not how many people, but who the work was done with and whether the project page says so.	A number cannot be checked; look at whether work done with a partner is marked on the project page.
Who owns the choice of tools	The tools the person knows. If your own team will take it over, those have to be tools your team knows too.	The tools the team knows. Same rule: anything your team would have to learn lands on your maintenance bill.

Questions this decision raises

It is a small job. Is a freelancer not enough?

A freelancer is enough when the job has few moving parts, and one person can be the right answer for you. Çatalca Merkez Kasap is one menu page: nothing behind it takes orders or holds stock, changing a price means editing the text, and nobody reprints the code on the table. The document to ask for is the handover list, so you can stand the page up again under your own account. Have it written before you sign.
Our freelancer stopped answering. The system is ours, but nobody can touch it. What do we do?

It gets taken over, and reading the code comes before writing any. KGM SsangYong had a corporate site already serving visitors when the work came to us: the code was read first, the parts that worked stayed where they were, and changes went only where the pages were heavy. Your system follows the same order, so first tell apart what is recorded from what sits in one person's memory. We draw the boundary of a takeover in the first conversation.
Won't an agency tie us to itself just the same?

It will, and that arrangement does not suit every business: when the author of a system also maintains it, you depend on the author. AlgoKlima's field app and office panel share the same record, so a new field on it moves both surfaces, and the team that wrote it knows where without looking. The tie costs you on the day that team is unavailable. Run the table on an agency too; what you test does not change.
How do we run acceptance?

You run it according to who enters the information. If one person enters it and no other role ever opens the screen, a walkthrough is enough and the signature can follow. If two roles touch the same information, acceptance becomes a scenario. AlgoKlima's scenario has a technician, with no signal, adding a note to a service record while the office edits another field of it from the panel; one record left when the connection returns means it passed. The role doing the work picks the scenario.
An agency wrote this page. Isn't it going to recommend an agency?

It does not: the row where one person is the right answer is written out, and every row applies to us. We give no headcount, because a number cannot be checked; capacity here comes from a development partnership, and shared work is marked on the project page under the partner's name. AlgoCar is ours to run and keep developing, and the chain from a work order to an invoice stays on our own maintenance calendar. Put the same two questions to us, in writing.