What should I assess when choosing a technology partner to develop custom software and apps?
Assess the partner on criteria you can verify before signing, not on sales promises. The five decisive ones are: source code ownership, which must pass to you contractually; who physically writes the code, meaning whether development is in-house or subcontracted; direct access to the technical team, not just to a salesperson; real projects in production with measurable numbers and references you can actually call; and a method that includes written requirements analysis, progressive releases, SLAs and evolutionary maintenance set out in black and white. To these add the supplier's business continuity, coverage of the skills you need (web, mobile, API, AI, IoT, cloud, security), GDPR and NIS2 compliance designed in from the start, the ability to integrate with the systems you already run, and a willingness to come to your premises and understand how you actually work.
How do I verify that the code will really be mine?
By requiring the transfer to be written into the contract rather than promised verbally, and by checking three concrete details: that what is transferred is the source code and the documentation (not a «perpetual right of use», which is an entirely different thing); that the code lives in a repository you can access from day one, rather than being handed over only at the end; and that there are no proprietary components of the supplier without which the software does not run. If the supplier reuses its own products in the project — which is legitimate and often beneficial — they must be declared and the terms of use must be clear upfront.
What are the red flags to stay away from?
The most reliable ones are seven. A lump-sum quote delivered in two days without ever seeing your processes. Reluctance or embarrassment when discussing code ownership. Being unable to speak with the people who will write the code. References made only of logos, with no production project you can verify. A plan with a single large release at the end and nothing usable before it. Integration with your systems deferred to «we will look at that later». And a quote far lower than the others with no technical explanation: it almost always means a different scope, and the difference will come back as change requests during the project.
Freelance, agency, system integrator or software house: which is better?
It depends on the size and lifespan of the project. A freelance is cheap and excellent on bounded work, but concentrates continuity risk on a single person. A web agency is strong on websites and communication, weaker on management software, integrations and critical systems. A system integrator assembles and configures third-party products: suitable for those who want off-the-shelf solutions, less so for those with unusual processes, and often with vendor lock-in included. A full-stack software house develops bespoke software around real processes, covers web, mobile, API, AI, IoT and cloud in-house and transfers the code to you: it is the right choice when the software must last for years and evolve with the company. For software that sits at the operational heart of a business, continuity and code ownership matter more than the price on the first quote.
Which questions should I ask at the first meeting?
These ten are the most useful: who will physically write the code, and may I speak to them? How do you reach the estimate, and what is excluded from scope? What goes into production within the first three months? At the end of the project, is the code mine, contractually? Have you already integrated systems like mine (SAP, AS400, a proprietary management system), and how? What happens if the key person on my project leaves? What SLA do you offer, and who answers if the system goes down at night? How do you handle GDPR and, where relevant, NIS2? May I see a project in production with its numbers and speak to that client? How do you price requests that emerge during the project? The answers to those ten questions say more than any sales presentation.
How much does the partner's geographical proximity matter?
It matters a lot during analysis and little during development. Genuinely understanding how a company works requires seeing the warehouse, the shop floor, the order desk: that is hard to do over a video call alone, and badly captured requirements are the number one cause of disappointing projects. During development, by contrast, remote collaboration tools make distance almost irrelevant. Codebaker is based in Bologna, works closely with companies across Emilia-Romagna and serves clients throughout Italy: we use proximity where it counts, which is understanding the process before writing any code.
How do I protect myself if the supplier disappears or changes team?
With four practical measures. Check how many years the company has existed and how many people work on your project, so you do not depend on one individual. Insist that the code lives from day one in a repository you can access, not on somebody's laptop. Require the architecture and the release procedures to be documented, because a documented project can be picked up by anyone. Use standard, widely adopted technologies rather than exotic solutions: the availability of skills on the market is itself an insurance policy. Codebaker has existed since 2019, has projects that have been in production for 3 and 5 years, and works exclusively with standard, open technologies.
Is the cheapest quote always the worst choice?
No, but you need to understand why it is cheaper. There are legitimate reasons: a leaner scope, the reuse of components already built, a technology the supplier knows particularly well. The dangerous reasons are different: a scope quietly reduced, integration with your systems left out of the count, no testing or error handling, maintenance not budgeted, undeclared subcontracting. The way to tell them apart is to ask the cheapest supplier to list what is excluded: if the list never arrives or stays vague, the price difference will come back as change requests.
Why choose Codebaker as your technology partner?
Because we meet the criteria listed on this page as standard practice: we are a software house based in Bologna, founded in 2019, that develops in-house — web apps, mobile apps, APIs and integrations, AI/LLM, IoT, cloud and NIS2 cybersecurity — and we transfer full source code ownership to the client, with no vendor lock-in and no per-user fees. Clients speak directly with the people writing the code, not only with a salesperson. We have projects in production with verifiable numbers: Granarolo (IAM integrated with SAP, 2,000+ users, -95% IT onboarding effort, 5 years in production), Conor (B2B e-commerce integrated in real time with AS400, 5,000+ customers a day, 300,000+ orders a year), Piusi (Flutter app with Bluetooth Low Energy, 10,000 users a day), CPR System (traceability of 25 million crates, -99.9% losses). And we build our own products, LoginMaster and Data Alchemy, which we put at the service of our clients' projects.
