Technical management for growing businesses: who restarts the import?
Once a month, the import process nearly grinds to a halt. A colleague spots it, starts it again and the orders flow through once more. Nobody writes it down, because it is fixed in no time. Moments like these are where technical management for growing businesses starts: with the small manual fixes that work as long as volumes stay manageable and the right person is around.
So I would start with one question. Who is responsible when your technology cannot keep up with the pace of your business? As long as there is no name next to it, a heavier server will only help you so much.
Growth turns a manual workaround into a risk
In the early stages a lot can be done by hand. Someone corrects an order or copies data between two systems. With more customers, orders and staff, a temporary fix like that quietly turns into a business risk.
On an e-commerce platform you notice it through more traffic, in a SaaS environment through heavier customer accounts. An agency notices it as soon as its clients depend on a stable application. At that point databases, API integrations, backups, access rights, monitoring and updates all have to fit together.
Who owns it when the import stalls?
The developer manages the code, the hosting provider the server and a third supplier the external integration. When something breaks, each party points to a different component. Meanwhile your operation is at a standstill or your customer is waiting for an answer.
With custom software this is harder still, because the application and the infrastructure affect each other. A slow page can come from the code. It can also be a database query, the caching, a server setting or an external API. If development and hosting are organised separately, finding the cause alone often takes far more time than it should.
My choice: make sure one party has overall control first, and only then look at the price per component. A specialised external service can sit alongside that perfectly well, as long as someone keeps an eye on how everything fits together, keeps the documentation in order and takes charge during an incident. If technology is not your core business, you do not want that coordination on your own plate.
LJPc combines custom development, infrastructure and management under one roof. Someone who knows the application and also manages the hosting can see more quickly where action is needed and which fix will hold.
Technical management for growing businesses starts with a list
Before you expand anything, you want these answers written down:
- Which systems are business-critical?
- Which integrations must not fail?
- Where is your data stored and how is it secured?
- How quickly can you recover after an error?
A check you can do today: list the business-critical systems and write next to each one who deals with it when it goes wrong. If a system has no name next to it, nobody owns it. If the same name keeps appearing, the knowledge sits with one person. Also ask when a backup was last actually restored. A backup only has value once the restore has been tested.
With those answers and your list of systems, day-to-day decisions become clearer. You assess updates and schedule them. You add capacity before a campaign or busy period causes problems. And logs and monitoring only pay off when someone actually acts on the signals.
A recurring ticket needs a root cause
Many companies have support in place: when something breaks, they submit a ticket. Management adds a party that knows your environment, spots patterns and carries out targeted maintenance.
Take the import from the start of this article, the one that nearly stalls every month. A management partner who sees that pattern works out whether the data flow, the database, the scheduling or the scalability needs to change, so that nobody has to step in next month.
The more you depend on digital processes, the more a recurring problem like that costs you. A short outage in an internal tool holds up work. An error in a customer portal costs trust. A slow checkout costs revenue straight away, and on top of that come the hours of a team busy with the wrong things.
A partner can only look ahead if they know what is coming. So tell them in advance about a product launch, marketing campaign or process change. In return, you can expect your partner to explain in plain language what a risk is and what the decision in front of you means for the business.
A customer reports the outage first
If you only hear about an outage through a customer, your management no longer fits the stage your business is in. There are more signs. Nobody can say exactly which systems depend on each other. Releases are nerve-racking, because rolling back is not properly arranged. Performance problems keep returning, responsibilities are unclear and someone steps in by hand.
Look beyond the number of incidents. An environment can seem stable while all the knowledge sits with one employee or the backups have never been checked. You only see that risk when that employee leaves or is off sick or something really goes wrong.
Skip the big migration for now
If you recognise these signs, a large migration project quickly comes to mind. I would first check whether better insight, targeted monitoring and a clear escalation route are enough. Management does not have to be extensive from day one. A small platform with few dependencies needs less than an environment that dozens of employees and customers rely on every day.
It comes down to the order you do things in. Insight and monitoring show which component is under strain. If you migrate without that information, you risk replacing the wrong part and carrying the manual restart over to the new environment.
It may also be that the infrastructure, code or integrations are genuinely due for replacement. Where that line lies depends on how much you rely on the system, on your growth plans, on the technical knowledge you have in house and on what downtime costs you.
When you choose a management partner, have them start with your operation, not with a standard package. Put your list of systems on the table and discuss how much downtime you can tolerate, when your peaks fall, which processes are critical to revenue and which integrations already cost time. At the start, also agree how your partner reports what is being managed and which work is carried out.