How to choose a software development company
Mesterséges Intelligencia Központ Kft. is a software development company based in Budapest, Hungary. In our view, a good choice comes down to three questions: does the developer understand the goal, can its offer be checked, and who owns the code and the system after handover.
In short: Write down the goal and the must-haves first, and only then ask for offers. Ask to see working software, a transparent process and access to the code; compare offers against the same itemised specification, preferably by measured size. The contract should also cover the source code and the usage rights, confidentiality, bug fixing, operation and how to exit.
The goal first: what does the software have to do?
Most bad choices start not with the developer but with a vague brief. If nobody has written down what the software has to do, every offer will mean something different, and there will be nothing to measure either the price or the finished work against. You do not need a finished specification (a good developer helps write one), but a few things are worth thinking through in advance:
- Goal: what problem the software solves, and how you will know it is a success.
- Users: who will use it, whether internal staff, customers or partners.
- Must-haves: what it cannot launch without, kept separate from the “nice to have” items.
- Existing systems: what it has to connect to (ERP, CRM, webshop, invoicing, bank).
- Data: what data it handles, including personal data.
- Constraints: whether there is a fixed deadline, internal rules, or hosting or security requirements.
It is also worth deciding whether you need custom development at all, or whether an existing product, possibly with a custom extension, would do. Our article Custom software or an off-the-shelf solution? helps with that.
The shortlist: whom should you approach?
You do not need to approach many companies; a few carefully chosen candidates are better than many superficial offers. Criteria for the shortlist:
- Similar work: has it built a system of similar size and nature, such as business software, a webshop, a mobile app or AI integration?
- Technology fit: does it work with the technologies your existing systems need to connect to?
- Scale: does the company's capacity suit the project? A large system needs several specialisms, a small task fewer.
- Language and availability: can it work with you in your language and your time zone?
Checking work and references
The strongest evidence is working software. Ask the candidates to show a system you can actually try, and to tell you exactly what their own part in it was. Much client work is covered by confidentiality, so names cannot always be given. In that case an anonymised description, a demo or the company's own products also say a lot.
If a former client gives a reference, ask specific questions: did the developer keep to the agreed scope, how were changes and bugs handled, did the client receive the source code, and are they still working together? A general “we were satisfied” says little; a client that still runs the system with them after handover says a lot.
A technical conversation
It is worth holding a technical conversation with each candidate, ideally with a technical person from your side present as well. What matters is not how confident the answers sound, but whether the developer asks questions and names the risks. Good questions:
- How would you approach it, and what would the first stage be?
- How would you connect our existing systems, and what do you need to know about them?
- How do you test, and who decides when a part is finished?
- Who will work on the project, and who will be our contact person?
- Where will the system run, and who is responsible for security updates?
- If artificial intelligence is involved: which data goes where, and what happens when the AI is wrong?
It is a warning sign if a candidate quotes an exact price and deadline after the first conversation without asking questions.
Process and communication
In software development, surprises rarely come from the code; far more often they come from communication. So it is worth asking how you will see progress along the way. Signs of good practice:
- Staged development: the work is split into stages, and at the end of each one you are shown working software, not just a report.
- Access to the code: the client can see the code repository from day one, not only at handover.
- A traceable task list: tasks, bugs and changes are visible in a shared tracker.
- A permanent contact person: someone who knows the project and can make decisions.
- Change management: a new or changed requirement is described, measured or estimated, and goes into the work only after approval.
Comparing offers
Two offers can be compared only if they cover the same scope. So every candidate should receive the same itemised description, and you should ask them which functions and what size their price covers. If the developer measures the functional size of the software with a standard method, in COSMIC function points for example, the size can be checked from the same specification; our article What is a COSMIC function point? explains the method.
If two offers differ widely, these questions are worth asking:
| Question | What it reveals |
|---|---|
| What size and which functions does the price cover? | whether they priced the same scope |
| What is listed as a separate item? | whether integration, data migration, graphics and operation are included |
| Which non-functional requirements did they allow for? | performance, security, accessibility |
| How do they handle changes? | what happens when a new requirement comes up along the way |
| What are the bug-fixing arrangements after handover? | what the fee covers, and what counts as extra work |
| Who will own the source code, and what rights do we get? | whether the system can be taken further by someone else |
| Is billing fixed-price or based on effort? | who carries the risk of the scope |
A fixed price works well when the scope is pinned down item by item; billing by effort is more flexible, but the risk of the scope stays with the client. Either way, what matters is that the scope can be measured and tracked. Our Pricing page describes how we price.
The essentials of the contract
The contract is what counts in a dispute or an unexpected situation. What follows is information, not legal advice: it is worth having the contract reviewed by a lawyer as well.
Source code and usage rights
The Hungarian Copyright Act (Act LXXVI of 1999, in Hungarian) protects computer programs, whether in source code or in object code, as works of authorship (section 1(2)(c)), and states that the economic rights in software are transferable (section 58(3)). The client therefore either acquires the economic rights or receives a licence to use the software; the two are not the same.
A few rules that make precise wording important: a licence agreement grants an exclusive right only if this is expressly stipulated (section 43(1)); if the contract does not specify the modes and extent of use, the licence is limited to what is indispensable for the purpose of the contract (section 43(5)); if the content is ambiguous, the interpretation more favourable to the author applies (section 42(3)); and the licensee may grant a licence to a third party only with the author's express permission (section 46(1)). It is therefore worth stating:
- the handover of the complete source code and documentation, stage by stage as well;
- whether the client acquires the economic rights, or what licence it receives: exclusive or not, modifiable or not, transferable or not;
- that the developer holds the rights to the code written by its staff and subcontractors;
- the list and licences of the open-source and third-party components used.
Confidentiality (NDA)
If the idea or the business data is confidential, it is worth signing a non-disclosure agreement (NDA) before discussing the details. It should state what counts as confidential information, who may access it, how long confidentiality lasts and what happens to the materials at the end of the work.
Bug fixing and warranty
The contract should say what counts as a bug (a deviation from the agreed requirement), how acceptance testing works, which severity levels exist, and how quickly the developer responds at each level. It should also state for how long the developer fixes, free of charge, defects that were hidden at handover, and what already counts as further development.
Operation and SLA
If the developer runs the system after handover, a service level agreement (SLA) sets out the terms: the committed availability, how to report incidents, response and resolution times by severity, maintenance windows, backups and reporting. What is not written down cannot be demanded in a dispute.
Exit plan
The exit plan answers the question of what happens if you do not continue with the developer, whether out of dissatisfaction or because the developer ceases to exist. Its elements:
- up-to-date documentation on installation, architecture and operation;
- the code repository, hosting, domain and cloud accounts in the client's name, or at least with the client's access;
- an orderly handover of passwords and access keys;
- data that can be exported in a standard format;
- cooperation in handing over to a new developer.
Data protection: the data processing agreement
If the developer has access to personal data during the work (for example because it runs the system or tests with live data), under the GDPR it typically qualifies as a processor, and a written data processing agreement is needed with it (GDPR Article 28). Among other things, it must state that the developer processes the data only on the client's documented instructions, ensures confidentiality and security, engages further processors only with authorisation, deletes or returns the data at the end of the service and allows audits.
Security practice
Security cannot be added to software afterwards, so it is worth asking how the developer works with it. A good starting point is the OWASP Top 10, a widely known list of the most critical security risks to web applications; the current edition is the OWASP Top 10:2025 (checked on 17 October 2026). The top three places are held by broken access control, security misconfiguration and software supply chain failures. Ask:
- How do you handle access rights, and how do you test that a user can see only their own data?
- How do you update the external libraries you use, and how do you find out if one of them is vulnerable?
- Where do you store passwords and keys, and who has access to them?
- Do you have code review and automated tests?
- How are backups made, and have you ever tried restoring one?
Freelancer or development company?
Either can be a good choice; the question is how big the task is and how long the system will live.
| Aspect | Freelancer | Development company |
|---|---|---|
| Communication | direct, with one person | through a contact person, with several specialists |
| Specialisms | one person's skills | several specialisms: interface, back end, mobile, operation, testing |
| Cover | the work stops in case of illness or departure | the team can take over each other's work |
| Capacity | for smaller, well-defined tasks | for larger systems and parallel work |
| Contract | directly with the specialist | with the company, which is responsible for the team's work |
| Long-term operation | depends on the freelancer's availability | can be provided in an organised way |
A freelancer suits a well-defined task, especially if the client has its own technical lead to direct and take over the work. If the system is part of the company's daily operation, needs several specialisms and will run for years, a development company is usually the lower risk. The exit plan and the handover of the source code matter just as much in both cases.
Warning signs
- An exact price and deadline after the first conversation, without any questions.
- No written specification, or an offer that does not say what it covers.
- The client cannot see the code and would receive it only at handover.
- A vague answer about who will work on the project.
- It is unclear who will own the source code and what rights the client gets.
- Reluctance to sign a data processing agreement or an NDA.
- No working software to show.
Checklist
| Question | All right if |
|---|---|
| Are the goal and the must-haves written down? | there is a short description that everyone understands the same way |
| Have we seen working software? | we have tried at least one similar system |
| Do they understand the task? | they asked questions and named the risks |
| Will we see progress? | staged demos, access to the code repository |
| Can the offer be compared? | it covers the same itemised scope, and the separate items are visible |
| Are the source code and the rights settled? | the contract names the handover and the extent of the rights |
| Is there an NDA and a data processing agreement? | signed where needed |
| Are bug fixing and operation agreed? | severity levels, response times, an SLA |
| Is there an exit plan? | documentation, access, data export |
| Did we ask about security? | concrete answers on access rights, updates and backups |
Frequently asked questions
Freelancer or development company?
For a well-defined, smaller task, an experienced freelancer can be a good choice, especially if the company has its own technical lead. If the system is part of daily operation, needs several specialisms and will run for a long time, a development company is the lower risk, because the work does not depend on a single person.
How do we compare two offers?
Only offers made for the same itemised specification can be compared. Ask both bidders what size and which functions their price covers, what is listed as a separate item, and how they handle changes. If the size was measured with a standard method, such as COSMIC function points, it can be checked from the same specification.
What should the contract include?
The scope (the itemised specification), the price and the schedule, the handover of the source code and the extent of the usage rights, confidentiality, the acceptance and bug-fixing arrangements, operation and the SLA, the exit plan and, if personal data is involved, the data processing agreement. This is information, not legal advice.
What happens if the developer disappears?
If the source code, the documentation and the access rights are with the client, another developer can take over the system. That is why it is worth seeing the code repository from day one, keeping the hosting and the domain in your own name, and putting an exit plan in the contract. Without these, taking the system further can be difficult and slow.
Who will own the source code?
Whoever the contract gives it to: under the Hungarian Copyright Act, the economic rights in software are transferable, but this is not automatic. The contract should state that the client receives the complete source code and exactly which rights it acquires in it. With us, too, the contract governs source code and usage rights.
How we can help
This is how we work: the first consultation is free, we write the specification together, we measure the size of the software in COSMIC function points, and the offer and the schedule are based on it. Development runs in stages, with a demo at the end of each; we sign an NDA on request, and after handover we also take on operation and maintenance. The contract governs source code and usage rights. Our How we work page describes the steps, and our Pricing page the pricing method.
We are currently developing a large ERP and CRM system; our own projects, which you can try, are on the Our work page, you can read about the company on the About us page, and the FAQ page answers common questions. If you are looking for a developer, write to us using the details on the Contact page.