Nearly every business in the Maldives rates a software company on the proposal. It arrives as a neat document with a price at the bottom, and it feels like the thing to compare. It is also the easiest part of the whole engagement to get right, which is exactly why it tells you so little.
A proposal is written before any of the hard parts happen. The measures below are the ones that still matter in month nine, when the novelty has worn off and the software has to keep earning its place.
1. What is running right now
Ask for software you can open today. Not a case study, not a slide, not a design file. A live address you can type into a browser or an app you can install. Anything a company has kept running has already survived the parts of software development that mockups never test: real users, real data, real load, and the day something broke at an inconvenient hour.
If a company cannot show you one thing running, everything else on this list is theoretical.
2. Who owns the code when it is finished
This should be written down before anything starts. Some studios hand over the full source. Some license it. Some keep it and rent it back to you every month. All three are legitimate models and all three have very different consequences in year three, when you want a change and the original team is busy.
The wrong answer is a vague one. If nobody will put ownership in writing, assume you are renting.
3. Where it is hosted, and who can reach it
Software has to live somewhere. Ask who controls the server, whose name the domain is registered in, and what happens if the relationship ends badly. A surprising number of small businesses discover, years later, that their own domain is registered to a former developer who has stopped answering email.
The domain, the hosting account and the code repository should all be in the company's own name from the first day, whoever is doing the work.
4. How support actually works
Every company says it offers support. Rate the specifics instead:
- What counts as support and what is billed as new work
- The hours it is answered, in Maldives time
- How you raise something at nine on a Friday night
- Who answers if the person you know is on leave
- What happens after the first year, and what it costs
A studio that has thought about support has answers ready. One that has not will give you a number of hours per month, which sounds generous and means nothing, because nobody counts them.
5. Local context, built in rather than bolted on
Software written for the Maldives has to handle things that software written elsewhere does not. Connections that come and go. Payment through local banks rather than the card processors the rest of the world assumes. Staff on rotation between islands. Suppliers who invoice in dollars while the books are kept in rufiyaa. Delivery that involves a boat.
None of this is exotic and none of it is difficult, but it has to be in the design from the start. Retrofitting local reality into a system built on other assumptions is where budgets go.
6. What the team does when it is wrong
Every software project has a week where something does not work. What separates studios is the response. Do you hear about it from them, or do you find out from a customer? Is there a fix and an explanation, or an argument about scope?
You can test this before you hire anybody. Send a hard question during the sales conversation, something they will have to check rather than answer from memory. The speed and honesty of that reply is a fair preview of what year two feels like.
7. Whether they will tell you not to build it
The most useful thing a software company ever said to us as a customer was that we did not need the thing we had asked for. A studio that will talk you out of scope is a studio that expects to be around long enough for the relationship to matter more than the invoice.
If every idea you float gets an enthusiastic yes and a number, you are talking to a sales process, not a partner.
Where Devcity stands
We build custom software, web platforms and mobile apps from Malé, and we run our own products on the same stack we sell. The point of sale system, the fleet platform, the business suite, the hosting and the mailboxes are all things we operate ourselves, which means the support burden of a bad decision lands on us first.
You can see what we build on the services page, the products we run on the products page, and the projects we have delivered in our work. If you are weighing a decision right now, tell us the problem rather than the solution and we will tell you honestly whether it is one we should be building.