Questions to ask a software company before hiring

The shape of the answer sorts questions for a software company: an address that opens, a list of what a company left untouched, or a reply naming where a record waits. What those three share is that the check falls to you and needs nothing further from the company. Nothing on these pages measures experience in years; each year in the portfolio belongs to one named project and sits on its page.

If every company you meet sounds alike, the fault may sit in your questions rather than in their answers: you asked something only they can verify. Every example answer below is either an address you can open right now or a field on a project page you can read without our help.

A good question is one whose answer you can check yourself

Answers made of years, counts and adjectives cannot be used to compare software companies, because none of them turns into an address that opens today, a named boundary, or a place and an order.

A checkable answer arrives in one of these shapes. An answer you open is an address: you type it into a browser and part of the claim appears on screen. An answer that names a boundary is a list of things not done: it is either written on the page or it is not. An answer to a “what happens” question names a place and an order: you listen for those names when the company talks.

“How many years of experience do you have” fits none of them. The answer does not open, is not a list, and names no place. To check it you would have to look inside the company’s own records, and you reach those records through the company. You think you are comparing two suppliers; you are placing two pieces of self-description next to each other.

The checkable version of the question is this: which of your work has been live the longest, and what is its address? When we are asked, our answer is an address. Kokudankokuya is among the oldest work we have live. The site opens at kokudankokuya.com.tr, we maintain it, and the year sits in the fact bar of its project page. You will not find that figure in the body of this article, because the project page is where the figure belongs. The blog hands you the address and the page, not the number.

The inverse is checkable too. Nowhere on this site is experience claimed as a count of years. A year you see in the portfolio sits in a project’s fact bar, and the fact bar names the work it belongs to. What we are saying is not “we do the same as everyone else” but “open it and look”. That is the rule in one move: a claim you can verify somewhere outside the party making it is a claim, and a claim you cannot is a sentence.

Some questions never make the list. Price, duration and payment model produce answers that cannot be checked until the work is finished. Whether the figure you heard in the meeting was right becomes clear at the end of the project, by which time the comparison is done and the decision is made. Where the gap between quotes comes from is covered in a separate article; duration and payment model are separate subjects of their own.

The rule stumbles in one place. A newly founded company may have nothing live, and the question about the oldest live work comes back empty. An empty answer is not a wrong answer. It is a statement of status, and a statement of status can itself be checked. Nobody gets eliminated for having nothing live; the class of the question simply changes.

Which of your work opens right now, and at what address

A reference given as a list of names says nothing until you call each name. Calling costs time, most buyers never do it, and the list therefore looks like evidence without behaving like evidence. An address behaves differently. You open it the moment the meeting ends, and part of the claim shows itself. A rehearsed answer still has to match the page you opened; when it does not, the discrepancy surfaces in your browser rather than in the room.

The address we give is Vipkurum. The institutions run on the same core, yet each one enters through its own domain and appears under its own brand. The list of institution addresses sits on the project page; open any of them and the brand you see belongs to that institution, not to Vipkurum. The system is live and we keep maintaining it.

Opening stops somewhere, and the limit is worth naming. The screen is visible; the core is not. A domain shows that branding changes per tenant. It does not show that student, parent and payment records never cross an institution’s boundary. What happens behind the panel is invisible from outside, and there is nothing to gain from pretending otherwise.

For the core, the question moves into another class: does adding an institution mean a new installation or a new record? A checkable answer says “a new tenant definition” and refuses to say “a new installation”. That difference is the only signal that tells you whether the institutions genuinely sit on one core. A company giving the second answer may be running a separate copy per customer, and no screen will reveal it. How the tenant boundary lives inside the data model is covered in why a new institution is a record rather than an installation.

The service-side counterpart of the same claim is written on our enterprise software page. When a company’s work runs behind a login, as an internal panel or a field application, there is no address to open. The question then moves straight into the boundary class or the “what happens” class. The rule holds; only the way you check it changes.

What did you leave untouched in the system you took over

If you are sitting on a working but ageing system, every company you have met has probably produced the same sentence: we take over any codebase. The sentence cannot be checked because it contains no boundary. Not one word in it says where the work would stop, which is exactly why two companies saying it sound identical to you.

The checkable counterpart comes in two parts: what did you leave untouched in the system you took over, and what did you add to the stack? The first asks for a list of things not done. A list of things done can expand without limit, declares no boundary, and every supplier can fill it. A list of things not done names a boundary, and a named boundary can be verified today.

On the KGM SsangYong corporate site our answer reads like this: sections that already worked were left alone, the work stayed where the weight was, and maintenance stays within the framework the brand’s own team already runs, with the cache layer as the one addition. The site is live and we maintain it. Both of those lines sit in the results section of the project page, so you can read the “stays within the framework” line there and hold it against the answer you heard in the meeting. That comparison of two texts is the whole check.

The second part gets asked less often and says more about the years after launch. If a new dependency went into the stack, the team maintaining the system has something new to learn. If nothing went in, whoever could maintain the system before the takeover can still maintain it afterwards. Here too the checkable answer names a boundary: on the SsangYong site the framework and front-end set were kept, and the one addition is named on the page.

A system you inherit cannot be treated as a new build, because its architectural decisions arrive as borrowed constraints. The written version of our own answer to the boundary question sits on the software consulting page.

If a company rewrote the system from scratch, its list of untouched sections comes back empty. That is not a wrong answer; it is simply not an answer to the takeover question. What changes hands at delivery, meaning source code, access and documentation, is a different question: we listed those items in what you receive at handover.

When “it works offline” becomes a checkable answer

Every business with a field team asks this, and the reply is nearly always the same: we support offline. The reply names nothing, so nothing about it can be checked. “Support” is an adjective rather than a behaviour, and it says nothing about what the application does when the connection drops.

What a checkable answer has to name is specific. Where the record waits: when a technician opens a record with no connection, where does it sit on the device itself? The order of departure: when the connection returns, in what sequence do the records leave? The conflict rule: how is the conflict resolved when office and field edit the same record? An answer that names them all has been checked. An answer that names none of them is an adjective, and adjectives do not compare.

Our own product is where we invite that check. We run AlgoKlima and keep developing it, and the names are written on its project page. A record waits in the phone’s local queue, the queue drains in creation order, and conflicting edits merge into a single record. AlgoKlima has no public address, so there is nothing to open here; the check consists of listening for those same names when a company answers you.

The place to run the check has to be a system the company operates today, not the software it will build for you. That software does not exist yet, and what to test at acceptance is a different question asked at a different moment. What you can examine now is whether the company can name these things about something already running.

The underlying question for a field application is borrowed from our article on applications that keep working offline: where is the record created? How the queue fills and drains is explained there; what matters here is which shape of the answer counts as checked.

If the work never leaves a building, the question does not apply. Where the chain of records runs from start to finish inside one workshop, the connection never drops and the question falls flat. And if a company simply says “we do not do offline”, nothing bad has happened: you are holding a boundary answer, which is a checkable one.

Do you have a product of your own, and which one is live

A company with its own products usually presents them as a list. A list cannot be checked, because nothing next to the names says what state they are in. The checkable version asks for a status per product: which one do you run, and which one are you still building?

AlgoCar is a product we run and keep developing. Work order, consumed parts and invoice move through a single chain, and stock movement is not typed in as a separate record; it comes out of the work order. New features keep arriving, which is why we do not describe the product as finished.

AlgoRandevu is a product we are building right now. Rather than burying the length of an appointment and what it attaches to inside one industry’s assumptions, we are leaving both as product settings. The first two result lines on its project page carry the same tense: they open with “The aim:” and “In development:”. Presenting a product that is not live as if it were would break the exact thing this article is trying to test.

Your action here takes one step. Open the product’s page, look at the status cell in the fact bar, and hold it against what you were told. The cell is never empty: a live product reads one way, a product under continuous development another, and a product still being built reads “In development”. If a product described as live shows “In development” on its own page, the answer has failed the check. The mark of a checkable answer is that a company does not lend its own product more maturity than its records show.

The second question for a company that runs its own products is where maintenance sits. How we live with maintenance in our own products, and how we plan it before launch for the one still being built, is covered in a separate article.

A company with no product of its own says so, and that too is a status statement you can check. It does not follow that such a company knows nothing about maintenance. All that follows is that you will have to check its maintenance answer somewhere else.

Who did you build this with: the answer that lives on the project page

“How many people are on your team” is a fixture of these meetings and carries almost nothing. The answer is a number. It does not say who will do your work, whether those people are booked on something else this quarter, or whether part of the job will come from outside. On top of that, there is no way to check the number at all.

The checkable counterpart is asked per project: who did you build this with, and does your project page say so? You read the answer on the page rather than in the room. Either a partner is named there or nobody is, and that is one of the few points where a spoken answer can be verified at all.

Resterm is the example we offer. The tool is live and working at calculator.resterm.com: a user enters a heating requirement instead of a product code, the software calculates and selects a suitable heater, and the selection attaches to a basket, the basket to a project, and the project to its customer. Who the work was built with sits in the fact bar of the project page, in the role cell, as a “Built together with” line.

The partner’s name is not repeated here. Credit is a field in a project record rather than a sentence in a marketing text. Credit that gets repeated cannot be checked: it can be typed onto any page, it has no source, and there is nowhere to go and verify it. Credit that gets recorded can be checked: it sits in one canonical place, that place opens, and the line is either there or missing.

The capacity question lands in the same place. We carry capacity through a partnership whose name is written on project pages, not through a headcount. A headcount would have given you a number you could not verify; opening the page and reading the role cell is entirely in your hands.

If a page names no partner, there are two possibilities: the work was done alone, or the credit was never written down. What separates them is whether the company’s spoken answer agrees with the page. Nothing here implies that a company working alone is worse. The only thing that follows is that this line can be checked.

Uncheckable question, checkable counterpart and how to check, side by side

The third column is an action you can perform without the company’s help; the fourth says where that action lands with us.

The table is not an elimination tool. A company that comes back empty on one row is not disqualified by that row; it moves you to another one. The only thing that eliminates is a spoken answer that disagrees with the page.

A checked answer has somewhere to go: your brief. Once you have verified something yourself, it stops being an impression and becomes a line you can write down. Turning a checked answer into a line you write into the brief yourself is covered in the article on why quotes differ; a line the brief leaves out gets filled by each supplier’s own assumption, and you see the price gap without ever seeing its cause.

If you are sitting on a working but ageing system someone else wrote, put the boundary question to us: what would we leave untouched, and what would we refuse to add to the stack? Our answer is written on the software consulting page, and the work that page links to is live at an address you can open. Checking it does not require our permission.