Why choose external developers, and when not to
It is the first day of your campaign and the webshop starts to crawl. Or a link with a supplier fails, and nobody in-house knows exactly where the problem is. At that point you do not have months to build a development team. For most businesses that is the most honest reason to choose external developers: technical delays hit your revenue, your customer service and your daily operations straight away.
So my advice is fairly blunt. If software is not your core product, put the technical work outside and keep ownership inside: who sets the priorities, who decides and who knows the process. If software is your product, I would do it the other way round.
Choose external developers for everything but your core product
Hiring one developer feels like the sensible first step. Knowledge close by, short lines. But that one person then also has to carry architecture, security, testing, documentation, deployment and monitoring. When they are on holiday or off sick, things stall.
That weighs heavily in companies where software drives the work. Think of a publisher that relies on a fast platform, an e-commerce business with complicated stock integrations or an agency that needs reliable environments for its clients. There your team should be busy with customers and processes, and every hour spent chasing error messages comes out of that time.
The exception is a company building a unique technology product that its competitive position rests on. Product decisions are made every day and the knowledge has to sit entirely in-house. In that situation I would invest in a strong internal product and development team.
Growth does not wait for your vacancy
A new customer segment needs a portal. The back office you keep up by hand becomes too error-prone. An existing application suddenly has to handle far more traffic. If you first have to recruit, onboard and set up processes, operations fall behind.
An outside partner starts with a clear brief and a way of working that is already in place. The gain is mostly in the groundwork: sharpening the requirements, spotting risks and working out what is technically needed. That often turns out smaller than you expect. Sometimes a targeted API integration or an internal tool is enough, where you expected a whole new application.
Capacity moves with you as well. For a migration, an app release or a peak period you bring in more development power for a while than for regular maintenance, and afterwards the same knowledge stays available for further development and support.
Your budget benefits too. You see what each project, improvement or maintenance question costs and can put a business case next to it. An in-house developer needs work that matches their level, and that starts to chafe as soon as demand shifts between frontend, integrations, infrastructure and mobile apps. An external team brings in the discipline each phase calls for.
One party for the code and the server
With several suppliers, an outage often goes like this: the developer points at the host, the host at the external integration, and the supplier of that integration back at the application. Your customer waits for an answer and your own team sits idle.
Software always runs in an environment, and that environment decides whether users get a fast system and whether an incident stays small. Hosting, performance, security, backups and monitoring and deployments therefore belong to the same responsibility as the code. A partner who knows both sides finds the real cause of a problem faster and builds new features with the environment in mind.
That is why LJPc in Assen deliberately keeps development, hosting and support under one roof. If you depend on your platform every day, it is the shortest route from report to fix.
The downside is that you become more dependent on one party. That is why the agreements below deserve more attention than they usually get.
Ask about source code and access before the quote
An hourly rate and a polished portfolio say little about how a partnership holds up when something breaks. Ask how a partner works during an outage, how knowledge is recorded and who you actually get on the phone. Then put in writing, before a line of code is written:
- who owns the source code;
- who has access to the environments;
- which security agreements apply;
- how support works during an urgent outage.
These are not legal details for later, but conditions for continuity.
Also check how you will report an outage. With an urgent problem you want to reach someone straight away who understands the context. At the same time you want to be able to trace afterwards which choices were made and what was done. Personal contact and a traceable process reinforce each other.
And look at your own side. Without clear goals, reachable decision makers and an owner inside your organisation, even a technically strong project stalls. A partner can advise, build and manage. Which processes come first for you is your call.
Start with one bottleneck and a small result
What I would skip is the long list of desired features. Start where it hurts. Where does your team lose time? Where do customers drop off? Which information gets entered twice, and which outage costs revenue or trust? Pick one of those.
Then agree on the first tangible result. A working integration, an improved ordering process or an internal dashboard that takes over manual work. That way you quickly see how the partnership runs and the project stays concrete.
Give the partner the context behind the brief. A developer who knows why an order has to be processed before a certain time makes different choices from someone who only receives a screen design.
Set aside room from the start for what comes after delivery: maintenance, security updates, performance improvements and small optimisations. Software changes along with your customers, processes and suppliers, and a system nobody keeps up slowly turns into the next bottleneck.
Today, write down the one bottleneck that costs you the most time or revenue this month, along with the name of the person who decides on it internally. With that half page, your first conversation with a technical partner has direction from the start.