How to Choose a Software House: 7 Questions to Ask

A generic portfolio is not enough. Ask for examples of projects similar to yours in sector, size and complexity, and check that they are real and that you can contact them.

For example, among the work you can look at there is the MedicHub case study: a multi-tenant management system for dental practices that AraLith developed from scratch with Laravel, with scheduling, clinical records, quotes and invoicing. Clients we work with include Tinexta Innovation Hub and Studio Torta.

What we offer as proof: verifiable references and case studies that also describe the technical challenges faced, not just screenshots of the final result. AraLith, a software house in the province of Rome, has been developing software since 2007.

Ask the software house you are evaluating who really follows the project, from analysis to delivery, and whether the people change during the work. Every handover carries a risk: lost context, requirements interpreted differently, integration bugs and delays.

How we work at AraLith: a single technical point of contact follows the project from analysis to delivery. The person who gathers the requirements is the same person who implements them, handles the release and answers questions after launch, with no handovers.

We have worked this way since 2007: the person who knows the project's architectural choices, trade-offs and business logic stays the same for the whole journey.

Warning sign: vague answers about who will work on the project or about the actual make-up of the working group.

Requirements change during almost every project. When decisions go through many layers, even a small change can turn into weeks of meetings and unexpected costs.

How we work at AraLith: if an unplanned requirement emerges, we discuss it directly with the project's technical point of contact, assess the impact on time and cost, and decide together whether to go ahead or postpone.

Every change request receives a documented impact estimate, and intermediate releases let you see the software working along the way, not only at the end.

Warning sign: «everything included» on custom development, which is impossible by definition, or extras that cannot be estimated before going ahead.

Source code is a business asset. Vendor lock-in is dependence on the supplier: non-transferable in-house frameworks, repositories accessible only on the supplier's server, proprietary licences that tie you technically and commercially for an indefinite time.

How we work at AraLith: at the end of the project the client receives the complete source code and full intellectual property, the Git repository with the change history, the technical documentation and all credentials.

We work on open source, market-standard stacks, Laravel, React, MySQL, PHP: technologies any developer can read, maintain and evolve, with no proprietary frameworks or licence dependencies.

To include in the contract: full access to the Git repository, technical documentation delivered at the end of the project, freedom to move to another supplier without restrictions.

Launch is only part of the work. After release you need fixes, new features and security updates: without written commitments on support times and terms, you risk being left without support exactly when you need it.

How we work at AraLith: we offer maintenance contracts with response and resolution times defined in writing. Evolutionary maintenance is optional, never mandatory, and it is handled by the same technical point of contact who knows the project's code.

Warning sign: «we'll talk when needed» or maintenance costs not defined before signing the initial contract.

Technologies change quickly. A technical partner must be able to tell an obsolete technology to abandon from a legacy system to modernise step by step, without rewriting everything from scratch.

How we work at AraLith: since 2007 we have followed the evolution of web development, from PHP 4 to PHP 8, from monolithic architectures to modular SaaS, from jQuery to React. That is why we know the practical problems of modernising a legacy system towards Laravel and React, such as data migration and the gradual switch from the old system to the new one.

Current stack: Laravel 13, PHP 8.4+, React, MySQL, CodeIgniter (legacy maintenance), PrestaShop, WordPress. Every technology choice is justified by the specific project.

Warning sign: obsolete technologies presented as a choice of stability, with no upgrade plan.

Delays are part of software development: the question is not whether they will happen, but how they are handled and when they are communicated. The more layers separate the people who develop from the people who decide, the later a delay tends to surface.

How we work at AraLith: the single technical point of contact who follows the project flags a risk of delay as soon as it emerges, not when it has already become a problem. Between the developer and the client there are no intermediate layers filtering difficult news.

Estimates are based on documented effort, with regular checkpoints and an update for every significant change.

Positive sign: documented estimates, regular checks, timely updates even when the news is not good.
Warning sign: «we know from experience» without an estimation method, or no regular progress reports.