Software developer for SMEs in Galicia: freelance, agency or in-house team

When a Galician SME decides to build custom software, the same question always comes up: do I hire a freelance developer, go to an agency, or bring someone on payroll? All three options make sense in different scenarios, and getting it wrong costs months and frustration.

This article isn’t a eulogy for the “tech partner”. It’s an honest analysis of when each option works, depending on your situation.

Scenario A · A one-off, bounded project (3-6 months of work)

Typical example: an SME with a warehouse that wants to automate receiving orders via WhatsApp. Or a distributor that needs to integrate its PrestaShop store with its ERP. Or a clinic that wants an internal app to manage appointments with its own logic.

Best option: a small agency or an independent team. The project has a clear start and end. An agency commits to a scope, delivers it, does light maintenance and moves on. A good freelancer can work just as well, with the advantage of lower cost and the downside of the bus factor (if they get sick, the project stalls). Large agencies rarely fit here — their structure is built for bigger projects.

Signs you’re on the right track: the provider asks for access to see how your real team works before closing the scope. They break the project into phases with deliveries every 4-6 weeks.

Warning signs: scope closed without having seen your processes. Payment 50% upfront and 50% on delivery (an incentive to finish fast and badly). No source code access in the contract.

Scenario B · Your own product or ongoing development needs

Typical example: you want to build a SaaS to sell to other SMEs in your sector. Or your company has continuous development requests and you’ve already run two or three paid projects with third parties that ended up more complicated than expected.

Best option: hire in-house (or a combination). When development is recurring, each iteration with an external provider adds coordination cost: explaining context, negotiating scope, waiting for availability. An in-house programmer with a few years of experience usually pays off from the fifth internal project onward, compared with continuing to rely on external providers.

Rough market ranges in Galicia: junior with a few years of experience, mid-level (3-6 years) and senior (6+) with a significant jump if there’s strong specialisation (AI, fintech, critical systems). Full-stack developers who combine backend, frontend and deployment are scarcer and command a premium over their bracket.

When it does NOT work: if you don’t have someone in-house with a mid-level technical profile who can lead the programmer. A developer without a technical person setting priorities ends up building what they find interesting, not what the business needs.

Useful hybrid: start with an agency for the MVP, hire in-house once the product validates in the market.

Scenario C · You don’t know yet what you need

Typical example: you know your company has inefficiencies but you don’t know if the solution is custom software, switching ERP, training the team or reorganising processes.

Best option: none of the three. Consultancy first. Hiring development without having done a prior data-based diagnosis is a waste of time. A high proportion of failed software projects at SMEs don’t fail because of poor execution — they fail because the problem wasn’t software.

Questions you should ask before hiring

To any of the three options (freelance, agency or in-house candidate):

1. “Tell me about the last project where you got it wrong.” The answer tells you everything. Good ones have one and tell it without dramatising it. Bad ones say “none, they always turn out fine” or give a vague answer.

2. “If I left the company and the code had bugs, how would I explain it to another programmer?” A good professional has minimal documentation, readable code, standard structure. A bad one leaves you with a proprietary system that only they understand, creating dependency.

3. “Which parts of the project will you NOT develop, and how do we solve them?” No one does everything well. The honest one tells you “we outsource this part” or “a standard tool does this better, and we integrate it”. The bad one says “I do it all myself”.

4. “What does maintenance look like after the first year?” Maintenance is the great hidden cost — incidents, small improvements, dependency updates, compatibility. Ask in writing how it’s billed and what’s included.

Warning signs specific to the Galician market

“I’ll build you whatever the Kit Digital voucher covers, for exactly that.” The pattern of the digitalisation agent with no criteria. The voucher defines what the grant pays for, not what your business needs. A serious professional tells you which parts fit Kit Digital and which require additional investment — they don’t sell you something useless just because the voucher pays for it.

“We use our own platform / our own in-house framework.” Often this is proprietary code the provider reuses with a fresh coat of paint. Ask whether you’ll be able to export the source code the day you want to switch providers. If the answer is “no” or “it’s complicated”, walk away.

“Scope closed without analysis.” If you’re given a proposal without having spent two or three days understanding your business, the scope is wrong. Either they’ve over-scoped for safety (they overcharge you) or they’ll cut scope halfway through the project (quality suffers).

“Discount if you sign today.” Artificial urgency. A software project signed under pressure fails more often than those with two or three weeks of calm negotiation.

And if it’s a logistics or warehouse project

Sector experience matters. Building software for a company with a warehouse, fleet or traceability needs requires understanding operational pain points that a generic programmer doesn’t know — picking schedules, routing logic, the reality of carriers, typical exceptions. See the 3 real logistics software cases to gauge who you’re getting close to.

What we offer at Rowan Tech

At Rowan Tech we work with Galician SMEs across all three scenarios. In scenarios A and B we take on development from start to finish. In scenario C we always start with the diagnostic phase before building anything, and when the analysis shows that the current ERP is part of the problem, we propose migrating to our ERP for SMEs with logistics operations, designed from the outset to integrate the automations (order intake, real-time stock, routes, reporting) that in other ERPs you have to bolt on as patches.

If you’re deciding between options, an initial conversation takes us 30 minutes and helps you avoid getting it wrong before signing anything with anyone — us included.