How to choose a software company for your project

Three software companies quote on the same system. One says 400,000 EGP and eight weeks. One says 1.6 million EGP and five months. The third refuses to quote at all until it has spent two paid weeks with your team. All three documents describe the same features in nearly the same words, so the words are not what you are choosing between.

What you are actually choosing between is four things none of the proposals states plainly: whether the company has systems running in production right now, who will sit at the keyboard, what it owes you after the last invoice, and who owns what when the relationship ends. You are not going to audit their code, and you should not try. All four are checkable before you sign, in a single meeting, with questions that have concrete answers.

Open something that is running today

Ask for two or three systems the company operates now, and open them while you are in the room. Not screenshots, not a slide of client logos, not a prototype in a design tool. A URL, a login to a demo tenant, an admin console with real or masked data.

Then ask the operating questions rather than the building ones. Who uses this, and since when. What happens when it stops at eleven at night — who is called, and how does the team know before the client does. What broke last, and what changed afterwards. A team that runs what it built answers in specifics: a queue added when December load arrived, a migration done on a Friday night, a backup restored once and how long the restore took. A team that only builds gets vague here, because it has never stood on the other side of a launch.

Ask for a reference client, and when you get one, ask about the month after go-live rather than the build. The build is where everyone behaves well. The month after is where you find out whether the company answers on the second day of a problem.

The people, named

Ask who will write the code. Names, roles, whether they are employees or subcontractors, and how many other projects each is carrying at the same time. Ask whether the person presenting to you will be involved after signature, and if not, ask to meet the person who will.

An unwillingness to name the team is one of the clearest signals available to you, and it usually means one of two things: the team is not hired yet and the hire depends on your deposit, or the work will be resold to a third party you never meet. Neither is automatically fatal, but both change what you are buying, and you should know which one you are buying.

Then ask the continuity question. If the developer who knows this system leaves in month six, what exists that lets someone else pick it up — written documentation, more than one person who has touched the code, an environment anyone on the team can deploy. Ask it plainly, because the answer tells you whether you are dealing with an organisation or with one person operating under a company name.

Ownership of the code, the data, and the accounts

These are three separate things, and they are routinely confused, including by sellers acting in good faith.

• The code. Who owns the repository at the end, under what licence, and whether that includes the internal libraries the company reuses across clients. Reuse is normal and usually good, but you need a written licence to keep using those parts if you part ways.
• The data. Can you export everything yourself, in a documented format, on any day, without asking permission. If the answer runs through a support request, you do not control your data.
• The accounts. The cloud account, the domain registrar, the DNS, the app store listings, the payment gateway merchant account and the third-party API keys belong in your company's name and on your company's billing, with the vendor holding access rather than title.

Put all of it in a schedule attached to the contract, not in a reassuring paragraph in an email. Ownership left undefined is not an oversight that gets settled amicably later; it is the single item most likely to make leaving expensive.

Reading a proposal

A serious proposal has four parts: scope, exclusions, assumptions, and price. Most buyers read the last one. The information is in the middle two.

Exclusions are the honest part of the document. A proposal with no exclusions section is not finished — either the seller has not thought about the boundary, or has decided you will discover it later. Ask directly: read me what is not in this price. Content and data entry, integrations to systems nobody on the call has seen, training, hosting costs, the second round of design changes, the mobile app you assumed was included.

Assumptions are the price-change list in disguise. Client provides product data in a clean spreadsheet. The accounting system exposes an API. Every assumption that turns out to be wrong becomes a change order. Go through them one at a time and ask which of them, if wrong, moves the number, and roughly by how much.

Then hunt for the deliberately vague. Phrases like integration with your accounting system, admin panel, reports and responsive design survive in proposals because they mean whatever is convenient at build time. Make them countable. Which accounting system, which version, does it have documented API access, has anyone on this team connected to it before. How many reports, with which fields and which filters. If they cannot answer, that part of the price is a guess and you are the one funding the guess. The same applies to a timeline agreed before any scoping phase — a date given in the first meeting is a sales artefact, not an estimate. What a custom system costs covers why two honest estimates for the same brief can differ by three to four times.

Fixed price and time and materials, honestly

Neither is more honest than the other. Fixed price does not remove risk; it moves the risk to the vendor, who prices it into a number you cannot take apart. Time and materials is cheaper when the work is well run and unbounded when it is not, and it only works if you actually read the weekly report.

The arrangement that fails least: a short paid scoping phase at a fixed price, delivering a written specification and an estimate you could take to any vendor, then fixed prices per stage against that specification. You pay a small amount to learn whether these people think clearly, before committing the large amount.

Why the cheapest quote is usually the most expensive

This is worth arguing rather than asserting, because "you get what you pay for" persuades nobody looking at a number half the size of the others.

A price is a statement about how many hours the seller expects to spend. A quote at half the others is not the same work discounted; it is fewer planned hours. The hours that come out are never the visible features, because features are what gets demonstrated at handover. What comes out is scoping, error handling, migrating your existing mess of data, tests, deployment automation, documentation, and the second pass over anything built in a hurry.

The cheap quote is not a smaller number for the same thing. It is a smaller thing, described in the same words.

Then arithmetic takes over. By month three the underpriced team is losing money on your project, and a company losing money behaves predictably: your work moves to the least expensive person available, response times stretch, and every request becomes a negotiation about whether it was in scope. None of this requires bad faith. It is what a business does when a contract stops paying for itself.

You pay the difference eventually, in one of three currencies: change orders, a rewrite eighteen months later, or a permanent operational cost — an import that was never properly tested, so a member of your staff checks every file by hand, indefinitely. Compare quotes as price plus the expected cost of reaching a working system, and the cheapest column usually moves. The expensive quote is not automatically better either. Ask what the extra buys in hours, people and stages, and make them show it. If they cannot, it is padding.

The first month, and the questions to take into the room

A good engagement is recognisable early. In the first week they ask more than they tell, and the questions are about your business rather than your preferences — who approves a discount above ten per cent, and which of your two customer lists is the real one. Some of it will feel tedious, which is the point: those are the details only you can settle.

By the end of the second or third week something runs. It is incomplete and unattractive, but it is at a URL you can open on your phone, and you can watch it change week to week. Decisions arrive in writing after each call, including the ones where they disagreed with you. Access to the environments sits with you, not only with them.

The bad first month has a shape too: long silences, a design file as the first deliverable with nothing running behind it, progress reported as a percentage you cannot verify, and questions from the kick-off still unanswered in week four. Early signs a software project is going wrong covers what to do when you see it, and the short answer is that acting in month one costs a fraction of acting in month five.

Take these into the meeting:

1. Show me two systems you operate today that I can open now. Who uses them, and since when?
2. When one of them broke last, how did you find out, and how long did the fix take?
3. Name the people who will write this code. Are they employees? What else are they working on?
4. Read me the exclusions. What is not in this price?
5. Which assumptions here, if wrong, change the number, and by how much?
6. Which of these integrations have you built before, with which system and which version?
7. Who owns the repository, the cloud account, the domain and the data? Show me the clause.
8. Can I export all my data myself, in a documented format, on any day?
9. What does support cost after go-live, what does it cover, and what is the written response time?
10. If the lead developer leaves in month six, what exists that lets someone else continue?
11. What do you need from me, and by when, for this timeline to hold?
12. What would make you tell me this project should not be built?

The last one is the most informative. A company that has never turned down work will not have an answer.

Before you sign

Settle support and ownership inside the contract rather than in the relief of finishing negotiations — most of a system's life is spent after delivery. If you want a system scoped properly before anyone prices the build, Softwiro can be reached here.