IT Support or Software Developer: Who Do You Call When You Need Both?

IT support is usually best suited to devices, user accounts, networks, Microsoft 365 and standard business applications.

Software developers are better suited to custom applications, integrations, APIs, automation and software changes.

But some SMEs regularly encounter issues that sit between the two.

If your business has a mixture of custom software, cloud services, websites, SaaS platforms and integrations — and no internal technical team to oversee them — you may need an ongoing technical resource who can investigate across those boundaries rather than asking you to decide which supplier to call first.

The exact scope varies between providers. The important difference is whether someone is responsible only for one technical area or can investigate across several.

Traditional IT support remains essential for many SMEs.

Typical responsibilities include:

• user accounts and permissions;
• employee computers and devices;
• Microsoft 365 and email;
• networking and connectivity;
• standard SaaS applications;
• backups and security tools;
• basic cloud administration.

If most of your problems involve these areas, an IT support provider may be exactly what you need.

The limitation appears when the issue involves software that has been developed or customised specifically for your business.

For example, your IT provider may be able to confirm that the server is online, the network is working and users can access the system.

But if an application is producing incorrect data, an API has stopped working or a business workflow needs changing, the problem has moved into software development territory.

Software developers work on the applications and processes that sit on top of your technical infrastructure.

An SME may need a developer to:

• fix a problem in an internal application;
• change a business workflow;
• build or repair an API integration;
• automate a manual process;
• modify a CRM or ERP integration;
• update an application after a third-party API changes;
• improve a customer portal;
• investigate a failed background process;
• add new functionality to existing software.

If you have a clearly defined software project, engaging a developer or development team is straightforward.

The difficulty is that many SMEs do not have neatly defined projects all year.

Instead, technical work appears continuously in smaller pieces.

One week it is a bug.

The next week it is an API problem.

A month later, the business wants a small automation.

Then a cloud configuration causes an application issue.

None of these individually looks like a major software project.

Together, they create an ongoing need for technical capability.

This is where many SMEs lose time.

The company may already have several capable suppliers, but each supplier is responsible for only one part of the environment.

The business itself becomes responsible for deciding where the problem belongs.

Your customers suddenly stop being able to submit orders through an online portal.

Hosting provider:

The server is running normally.

IT provider:

The network and user access are fine.

Software vendor:

Our API is available.

But customers still cannot submit orders.

Someone now needs to:

• inspect application logs;
• test the API;
• check authentication;
• review recent changes;
• inspect cloud configuration;
• determine whether a background process has failed;
• contact the relevant third-party provider if necessary.

The problem is not necessarily that any supplier has failed.

The problem is that nobody owns the complete technical issue.

For an SME without an internal CTO or technical team, that ownership gap can become surprisingly expensive.

Not necessarily.

Some businesses have enough software work to justify employing their own developer or engineering team.

Many SMEs do not.

They sit somewhere in the middle:

Too much technical work for purely ad-hoc support, but not enough to justify another full-time employee.

The workload may also be unpredictable.

One month could include:

• fixing several software bugs;
• changing an integration;
• investigating a performance problem;
• modifying a report.

The next month could involve:

• a cloud issue;
• a small automation;
• a new API;
• a third-party system change.

This type of workload does not always fit naturally into either traditional IT support or project-based software development.

What the business often needs is continuity of technical ownership, rather than another permanent headcount.

Your situation may fall into this gap if several of the following sound familiar:

• Your IT provider regularly tells you that a problem requires a developer.
• Your developer handles software but does not understand the rest of your technology environment.
• Small software changes continue to accumulate.
• You rely on several connected business systems.
• Different vendors become involved whenever something breaks.
• Your team is often unsure who should investigate a technical problem.
• You have ongoing development needs, but not enough work for a full-time software engineer.
• Nobody has a complete understanding of how your website, cloud services, integrations and business applications fit together.

The common issue is not necessarily lack of technical expertise.

It is lack of continuity and ownership across different technical areas.

For fragmented technical work, continuity can be just as valuable as technical skill.

A new supplier often needs time to understand what the system does, how it was built, where it is hosted and which other platforms it connects to.

Someone who already knows the environment starts with that context.

An engineer who has worked with your systems over time knows where to look first.

They may remember that a similar problem happened six months ago, understand which integration is fragile or know which third-party supplier needs to be contacted.

Technical decisions are easier when the engineer understands how the business actually uses the software.

A change that sounds small technically may affect a critical business process.

Long-term context helps avoid treating every request as an isolated ticket.

An ongoing engineer does not need to replace every specialist your business uses.

There will still be situations where another provider is the right person to solve the problem.

A network outage may belong with your IT provider.

A Microsoft 365 issue may be handled by an MSP.

A security audit may require a cybersecurity specialist.

A major software initiative may require a larger development team.

The difference is that your business does not always need to determine this first.

A technical resource who understands the wider environment can investigate the issue, resolve what falls within their expertise and coordinate the right specialist where necessary.

Instead of asking:

Which vendor should I call?

you can start with:

Can you work out what's happening?

For an SME without an internal technical team, that can remove a significant amount of management effort.

Another common problem is work that is too small to become a formal project.

For example:

• add another field to an internal application;
• adjust an automated email;
• change an approval workflow;
• fix a report;
• update an API;
• improve a dashboard;
• investigate an intermittent error;
• automate a manual spreadsheet process.

Individually, these tasks may only require a few hours.

But waiting until there is enough work to create a larger project can leave the business with a growing backlog of small inefficiencies.

Using a different developer each time creates another problem: every new person needs to learn the system again.

This is one reason some SMEs prefer to maintain access to the same software engineer over time rather than treating every change as a separate development project.

A simple way to think about it is to look at the questions your team normally asks.

There is no need to combine these models if your requirements are straightforward.

If standard IT support covers almost everything you need, adding software engineering capability would create unnecessary complexity.

Likewise, if you have a single defined software project, a conventional project team may make more sense.

The combined model becomes relevant when these different types of work occur repeatedly.

For many SMEs, the choice is not really:

IT support or software developer?

The more useful question is:

Who is responsible for understanding our technical environment well enough to work out what needs to happen when something changes or breaks?

As businesses adopt more SaaS products, integrations, cloud services and custom software, technical problems increasingly cross supplier boundaries.

A small company may not need a CIO, an IT department and a software development team.

But it may still need someone who knows how its systems fit together and can take responsibility for getting technical work resolved.

That could mean fixing the software directly.

It could mean investigating an integration.

It could mean making a small application change.

Or it could simply mean identifying the right external specialist and coordinating the solution.

The important part is that the business does not have to reconstruct its technical environment from scratch every time something happens.

If your business has recurring software, integration, cloud and technical issues — but not enough work to justify a full internal development team — Shinetech provides access to a dedicated software engineer on a flexible monthly basis.

The same engineer can build familiarity with your systems over time, handle ongoing software work and help investigate issues that sit between different technical suppliers.

See how ongoing engineering support works →