Is it realistic to scale a dev team when our core platform is written in Harbour (xBase dialect)?
Posted by sieook@reddit | ExperiencedDevs | View on Reddit | 24 comments
I’m leading product and technical operations for a payments platform that’s been around for over a decade. Our core system is written in Harbour — the modern open-source xBase/Clipper dialect that compiles to C. It’s rock solid and powers thousands of active users daily, but as we move into a growth phase, we’re hitting a common challenge:
Can we realistically scale — both technically and from a hiring perspective — around a niche language like Harbour?
A bit of context: - The platform has matured significantly, with deep business logic and payment integrations baked into the Harbour codebase. - The system is stable, fast, and battle-tested, but it’s not exactly the stack new developers are learning in 2025. - We’re now at a crossroads: continue investing in this tech and train new devs internally, or begin a phased modernization (e.g., introducing a new API layer in a more mainstream language).
I’m interested in hearing from experienced devs, tech leads, or anyone who’s faced a similar inflection point: - Have you successfully scaled a team or product on a legacy or niche stack? - What hiring or training models actually worked? - If you transitioned to a new stack, how did you manage that without disrupting your core business?
We’re not afraid of modernization — we just want to be thoughtful about whether the real barrier is the language or the talent strategy.
Appreciate any insights or war stories from those who’ve been through this before!
YahenP@reddit
Clipper You said Clipper! A tear of nostalgia rolled down my cheek. Oh my God! How gorgeous my hair was back then! This is so unusual! 30 years. It's been 30 years since I last touched this with my hands.
sieook@reddit (OP)
Our “brand” has been around for 10 years. It was the culmination of a few companies merging, and one of the companies owned the gateway and software, and that company owner is now our President and CTO.
Hot_Slice@reddit
Someone who is experienced, and already a polyglot in multiple languages should be able to onboard with no problem. You just need to pay them appropriately to give up their other opportunities, and the damage it does to their resume to work in such a language.
Choperello@reddit
Realistically your options are to get a new dev who doesn’t realize what they’re getting into and teach them.
Or get an experienced dev who knows what they’re getting into and PAY them with a capital P.
The problem with your setup is that it’s a massive drag on one’s resume. You’re asking someone to go deep and build expertise in things nearly no one else cares about. They’re forgoing building more marketable skills in order to work for you. A experience dev will realize that a junior one might not. So pick between green and cheap and teach them everything or experienced and expensive.
(To be clear, the junior dev is screwing up his skill set and resume to an even higher degree. But I guess creating new xBase devs requires some blood sacrifice somewhere)
AftyOfTheUK@reddit
I see two main ways forward... the the one I would probably choose would be to move in a microservices direction and make new features where possible into microservices built on a new framework. Then consider abstraction out features from your primary platform over time into microservices
The second choice would be to hire more experienced developers who have an interest in trying something unusual but you would probably need to pay them a significant additional stipend if their should are going to atrophy, unless you can golf work for them in modern languages/frameworks alongside you existing work.
LoveThemMegaSeeds@reddit
AI slop
Difficult-Vacation-5@reddit
Just because of the formatting?
johnpeters42@reddit
"AI slop" is the most generous assumption. The other one is that OP actually writes in that dialect of corporate-speak on their own.
jonmitz@reddit
Seriously why is this garbage being upvoted
MathmoKiwi@reddit
"Harbour", that's a name I haven't heard in a very very long time! (I used to work as a SWE myself in another base dialect, arguably the most popular one ever)
Am surprised you say it's a ten year old system, as surely even 10yrs ago the writing was very plainly on the wall! And it would have been clear that Harbour was an evolutionary dead end that shouldn't be chosen.
Erutor@reddit
This will be a hard sell for a new dev. Honestly, it might be evil to hire a new developer and have their first real world experience be a super niche language with not a lot of possibilities for the future.
You might have better luck trying to hire a few very experienced devs who are interested in learning things that are new to them and do not really care so much about following the market.
However, this not impossible...
I have done something like this when I inherited a team running a COBOL product and another time one that had a VB6 product. The key to making a transition into a more modern architecture and tech stack was to start building adjacent but disconnected services to provide features, a middle layer to interface between the legacy solution and the services, and then gradually migrate features. This approach also allowed me to hire new developers to work on the new shiny stack while leveraging domain knowledge from the legacy team and ramping the legacy team up on the new tech stack.
Surprisingly, many of my new devs decided they did want to learn the old stack, as long as they were also working with new shiny. Like me, they were excited they had a chance to work with COBOL (less so VB6) in this century despite thinking they were too young to ever have a chance to experience that part of tech history. It was helpful to identify the things that are actually interesting, useful, and good about the legacy stack, and include new developers in the process of figuring out how we can use the new solutions to deliver some of those same values. This elevated their thinking so they had a chance to do some design work they might not otherwise have had the chance to tackle.
Abject-Kitchen3198@reddit
Yes. Should not be an issue for experienced dev. He might have even worked with same or similar tech at some point. For some (or a lot) might be even more exciting than learning a modern JS framework.
Erutor@reddit
At least you would have well known bugs instead of having to discover them all yourself, and wouldn't have to wonder how much of your work would have to be re-done when version + .01 releases. :D
thecoffeecrazy@reddit
Scaling a team around Harbour is tough given its niche status, but focusing on hiring adaptable senior engineers who value complex problem-solving over trendy tech stacks could work. Have you considered creating internal training programs to bridge skill gaps while gradually introducing modern tooling alongside the legacy system?
backfire10z@reddit
For clarity, I’m not an experienced dev, but a new grad new hire.
The company I currently work at (and my first job out of college) uses C++, but has introduced some custom methods to write code such that it is like half a new language. We have a month-long bootcamp training people on how to read and write this code, as well as fundamental concepts around the code base. I learned it just fine.
behusbwj@reddit
You’re concerned about tech when you should be concerned about people. The talent pool is going to be a lot more restricted. You may find gems but it’s more likely that you’ll get the devs who couldn’t find anything else. Your team might scale, but not deliver the results you want.
LeadingPokemon@reddit
You sure you’re leading this project? And you’re still questioning if your core platform should built on a language with like 10 global users?
arihoenig@reddit
Wow... What a blast from the past. I remember paying $500 for Ashton Tate dBaseIII in 1980 something and then I remember the clipper craze and wow... I thought that all died decades ago.
martinbean@reddit
If you’re using an esoteric language then the talent pool of suitable candidates is going to be small… and competitive. And when there’s competition, it means you’re going to have to pay more to attract talent and stop them working from one of the other few employers looking for that specific skill set.
I have no idea the size of your codebase(s), but if the company isn’t adverse to modernising then I’d seriously consider that route, picking a more popular language where you’re not going to struggle to hire candidates at the level you need and want.
dmazzoni@reddit
I don't know anything about Harbour, but what you describe is in general what it's always like to hire at a big tech company. At most big tech companies, most of the frameworks, and even some of the languages, are proprietary. Even when we use well-known languages and frameworks, the way we use them is often quite foreign to people who have previous experience with them.
And, it's fine. We focus on people who are eager to learn. We let candidates interview in their own strongest language. We compare candidates based on general skills, not whether they happen to know any technology we use.
I also think that most development skills transfer. The years I spent working on proprietary or obscure languages, I still learned valuable development skills that were helpful on other projects.
sayqm@reddit
But when you join big tech you have the "prestige" on your CV and the pay. Usually those smaller companies don't offer that
dmazzoni@reddit
Sure, so if you want big tech level talent you'll have to pay well or offer better benefits or WLB.
But if you're just looking for good developers, these days a paycheck and real experience sure beats being unemployed. You shouldn't have any shortage of candidates.
Factory__Lad@reddit
I’m getting flashbacks of an early internet era where I was hired for a C++ job that rapidly became CA-Clipper.
Never again. Friends don’t do this to friends.
I still remember a magazine about CA-Clipper from those far off days where a colleague looked at the people on the cover and said in wonderment “They’re one step away from coneheads”
Sorry, I’m sure it is a business requirement and all, so maybe you could find end of life devs or reformed COBOLers who would see it as a challenge.
dedservice@reddit
AI slop astroturfing? C'mon, man.