“Instead of paying a vendor NT$20,000 a month, why not hire my own engineer? He could handle other things on the side.” About six months after a system goes live, a lot of owners start thinking this. Especially when every field change means waiting for the vendor to find time, or when the maintenance fee gets paid and you can't see what the vendor actually did. Hire your own person, sitting in the office, someone you can call over just by turning around. It sounds cheaper and safer.
I'm Johnny Yang, founder of Brightstream Technology in Taiwan. Seven years in business, 252+ projects across 32+ industries, and over NT$20,000,000 in systems delivered per year. When I ran my own businesses, I went through six industries and lost NT$7,000,000 in three years. The most expensive lesson was “keep hiring”: every time we got stuck, I hired another person. So when an owner wants to bring an engineer in-house, I ask him to finish the math first.
The short answer: hiring your own engineer just to maintain a system that is already live is usually not worth it. An engineer's cost is not just the monthly salary. It is also employer contributions, recruiting, equipment, the time you spend managing him, and the risk that nobody looks after the system when he takes leave or quits. A maintenance contract buys a company's commitment to your system: there is a contract, there are deadlines, and it does not break because one person leaves. Hiring in-house is worth it in only one situation: your company has steady new development work every month, the system itself is your core product or competitive edge, and someone in the company can judge whether the engineer is doing good work. If you don't have all three, the better setup is one internal point person who understands your processes, plus an outside maintenance contract.
What does one engineer really cost per year?
When owners work out the cost of an engineer, the first number is usually the monthly salary. But the salary is only the start. Below is one hypothetical example. Every number is an assumption. Replace them with the actual market rate for your region and the level you're hiring.
Say you want to hire an engineer who can maintain a system on his own, at NT$60,000 a month, with a year-end bonus of 2 months' pay (standard in Taiwan). As the employer, you also pay labor insurance, national health insurance and labor pension contributions. Assume these add up to about 15% of the monthly salary. Then there is equipment: a computer, software tools, a server test environment. And the recruiting cost before you find this person.
| Item (hypothetical) | How it's calculated | Annual amount |
|---|---|---|
| Salary and year-end bonus | NT$60,000 × 14 months | NT$840,000 |
| Employer contributions (labor and health insurance, pension) | 15% of monthly salary × 12 months | About NT$110,000 |
| Equipment and tools | Computer, software licenses, test environment | About NT$50,000 |
| Recruiting | Job posts, interviews, probation ramp-up, spread over year one | About NT$50,000 |
| Total | About NT$1,050,000 |
This table still leaves out two things. First, the time you spend managing him: assigning work, checking progress, judging whether he got it right. Second, the cost when he quits: the handover period, recruiting again, and the months a new hire needs to learn the system. Both are hard to estimate, but every company that has kept an engineer on staff has paid them.
Management time is especially easy to underestimate. An engineer's work doesn't show up like sales figures or warehouse shipments. An owner can't tell at a glance what he did today. So either the owner spends time every day chasing progress, or he stops checking altogether, until one day he finds out that something he asked for six months ago still isn't done.
The resignation cost is paid all at once. When an engineer who knows the system leaves, the new hire needs weeks to months just to understand what the previous person wrote. During that time, the system effectively has half a person looking after it. If the previous engineer left no documentation, it takes longer.
For comparison, Brightstream's maintenance fee starts at NT$20,000 a month. At NT$20,000, that's NT$240,000 a year, with the quotation based on system size. On the numbers alone, that's more than a fourfold difference. But the comparison isn't really fair, because the two options buy different things.
What does a maintenance fee buy, and what doesn't it buy?
First, what it buys. A maintenance contract buys someone who knows your system, someone who picks up when things break, and agreed deadlines. Take my own maintenance contract as an example: critical issues are patched within 24 hours of being reported, high-risk issues within 72 hours. During the maintenance period, adjustments to UI/UX, fields and report layouts within the written feature list cost nothing extra.
Now, what it doesn't buy. A maintenance contract does not include new features. A process that didn't exist before, a new integration, a new module: those go back to implementation or development, with a separate scope. If your company has a pile of new requirements every month, a maintenance contract won't cover you. That's a fact.
So the real comparison isn't “NT$1,050,000 vs. NT$240,000.” It's what your company's workload actually looks like. If the system is stable and only needs a few adjustments a year, an in-house engineer will have nothing to do most of the time, or the owner will pull him into a pile of “while you're at it” odd jobs. On the other hand, if there are new features to build every month, a maintenance contract plus separate development fees may add up to close to the cost of one person.
For how to calculate a reasonable maintenance fee, and which systems suit annual, monthly or per-incident pricing, see How to price system maintenance fairly.
Do the math first: how much work does your system actually need in a year?
Whether to hire comes down to workload, and most owners don't actually know how much work their system generates in a year. The method below needs no tools. You can finish it in one afternoon.
Step one: dig up everything system-related from the past year. Sources include your LINE group with the vendor, email, quotations, and things colleagues have complained about out loud. It doesn't have to be precise. Just get it on a list.
Step two: sort each item into three categories. Category one is bug fixes: something that should work is broken. Category two is small adjustments: changes to fields, wording, report formats. Category three is new features: things that didn't exist and have to be built from scratch.
Step three: see how much each category accounts for. If most of it is bug fixes and small adjustments, that is exactly what a maintenance contract covers, and hiring in-house will rarely pay off. Only if new features fill a whole year, and next year looks like even more, does the hiring question come up.
Step four: look at when the urgent issues happen. If many problems happen at night or on weekends, say you ship on weekends or your stores open in the evening, then an engineer working office hours can't catch them either. What you need is service hours written clearly into the contract, not a person.
After doing this once, many owners find that the reason they wanted an engineer wasn't a heavy workload. It was that “dealing with the vendor is a hassle every time.” What needs fixing then is how you communicate and what the contract says, not another hire.
“Our own person is easier to reach”: what's right and wrong about that?
First, what's right about it. Your own person really is easier to reach. He sits next to you, understands your business, doesn't need the background explained every time, and you don't wait for him to fit you into a schedule. Plenty of outsourcing vendors respond slowly and are costly to communicate with. After an owner gets dragged along once or twice, wanting to hire in-house is a natural reaction.
But the real problem is this: one person is not a team.
First, one person has roughly two hundred-some working days a year. When he's on leave, sick or abroad, and the system breaks, there's nobody. A maintenance contract is with a company, bound by a contract and deadlines. How they schedule people, who covers for whom, is their problem, not yours.
Second, one person becomes a new lock-in. Many owners worry about being locked in by a vendor. Then they hire an engineer, and how the system is written, where the passwords are, how the server is configured, all of it lives only in his head. The day he resigns, you'll find you're locked in tighter than any vendor ever had you, because a vendor at least has a contract, and an employee only has to give one month's notice. What happens when a company's key knowledge sits with one person is laid out in Your company's know-how lives in your veteran employees' heads. Engineers are no different.
Third, you can't judge whether he's doing good work. Most owners can't read code. When the engineer says “this will take two weeks,” you can't tell if it should be two days or two months. When he says “the system needs a rewrite,” you just have to believe him. With an outsourcing vendor, you can at least compare prices and bring in a third party to assess. With your own employee, that's hard.
This is also what I learned losing NT$7,000,000 back then: hiring someone every time you get stuck looks like solving the problem. In fact it turns the problem into “more and more people to watch.” I wrote that lesson up in Headcount is the most expensive mistake.
Three setups and which companies they fit
In practice there are more than two paths. I lay the choice out as three setups, depending on where your company is now.
| Comparison | Hire one in-house engineer | Sign a maintenance contract | Internal point person + outside maintenance |
|---|---|---|---|
| Annual cost (hypothetical) | From about NT$1,050,000 | Monthly maintenance fee × 12 | Part of the point person's time + maintenance fee |
| During leave or after resignation | Nobody looks after the system | Vendor reassigns staff, contract sets deadlines | Outside team handles tech, point person handles communication |
| New feature development | Possible, depends on his skills | Not included, negotiated separately | Not included, negotiated separately |
| Who judges quality | Hard for the owner to judge | Contract deadlines and acceptance | Point person signs off against the feature list |
| Lock-in risk | Locked to one person | Locked to the vendor, protected by contract | Accounts and data stay with the company |
| Fits | Long-term development volume, a technical lead in place | Stable system, few new requirements | Most companies with 50–200 people |
The third setup is the one I recommend most often. The internal point person doesn't need to be an engineer. It's a careful employee who understands the company's processes. They collect colleagues' issues, judge how serious each one is, communicate with the maintenance team, and confirm things are actually fixed. It takes part of their time, not a full-time role. But it keeps the company in control of its own system instead of handing everything to outsiders.
For a fuller look at the IT staffing options for small and mid-sized businesses, see Should you build your own engineering team? Three IT staffing models. That post covers overall staffing. This one only does the math on maintenance.
When is hiring your own engineer actually worth it?
This isn't saying hiring in-house is always wrong. If you meet three or more of the four conditions below, hiring in-house is a reasonable choice.
1. You have steady new development work every month. Not small tweaks you think of now and then, but enough development to fill a six-month work list. Without that volume, the engineer sits idle, or gets pulled into work he shouldn't be doing.
2. The system itself is your core competitive edge. For example, your system faces customers directly and is part of the service you sell, so the faster you change it, the better business gets. In that case, keeping development capability inside the company makes sense.
3. Someone in the company can judge the engineer's quality. It can be a technical lead, or a long-term outside advisor. If nobody can judge, you have to believe every word he says.
4. You can afford two, not one. One engineer is a single point of failure. Two can back each other up and check each other's work. If the budget only covers one, the risk is actually higher than signing a maintenance contract.
If you meet none of the four, or only one, sign a maintenance contract and assign an internal point person. If you meet two, start with a maintenance contract plus development as needed, watch the actual workload for a year, then decide. For which clauses to spell out when signing a maintenance contract, check against the 12 items in What a system maintenance contract should include.
FAQ
We only have one system. Is hiring an engineer a waste?
Most likely, yes. Once a system is stable, the maintenance workload usually isn't enough to fill a full-time role. Either the engineer sits idle, or he gets pulled into fixing printers and sorting out the network, work that doesn't need an engineer's salary. With only one system, a maintenance contract plus an internal point person usually makes more sense.
Our outsourced maintenance vendor responds slowly. What should we do?
First check whether the contract specifies response and fix deadlines. If it doesn't, add severity levels and deadlines before you renew. If it does and they don't meet them, that's a reason to switch vendors. Also look at your own side: if there's no fixed point person, and five people send issues five different ways, the vendor will struggle to prioritize. Don't jump straight to hiring in-house because of slow responses. That trades a smaller problem for a bigger risk.
Our in-house engineer quit. How do we take over the system?
First confirm that the source code, server accounts, database and third-party service accounts are all in the company's name, and that you can get the latest version. Then have someone assess the state of the system before deciding whether to hire a replacement, hand it to outside maintenance, or partially rebuild. Ideally, get the documentation and accounts in order while he's still employed. Don't wait until he resigns to start.
If we sign a maintenance contract, do we still need someone inside who understands the system?
Yes, but it doesn't have to be an engineer. You need one internal point person who understands the company's processes, knows what each function in the system does, can judge how serious an issue is, and can confirm it's been fixed. With that person in place, you don't have to wait for the vendor to tell you everything.
You're not buying a person, you're buying a system that doesn't go down
In one sentence: to maintain a system that's already live, what you need isn't a person. It's a system that keeps running no matter who's on leave or who quits. Only when development volume is steady and someone can judge quality is it worth keeping an engineer on staff. In every other case, one internal point person plus an outside maintenance contract costs less and is more stable.
If you're running these numbers now, or the person who looked after your system just left, take a look at how system maintenance and takeover gets assessed first, then decide whether to hire or sign a contract.
