Two questions will trouble you more than anything else when you build your own software: what to build it in, and who builds it. And because both sound terribly technical, most people just hand them off to the first programmer they meet. That’s a mistake. Choosing the technology and choosing the people are half business decisions, not technical ones. They shape how much the software will cost you over the coming years, how quickly you can change it, and whether you can one day walk away from it without losing your shirt.

The stack: don’t chase hype, pick for the problem

Technology follows the same rule as gear for the mountains. You pick for the weather, not for what’s trendy right now. The new framework everyone’s tweeting about might solve three problems and hand you ten more, because nobody really knows it yet and in two years nobody will be talking about it.

A good stack shows three things:

It fits your problem. You want different tools for an online store, different ones for an internal record-keeping system, different ones again for something that crunches data in real time. Start from what the software does, not from your vendor’s favorite language.
Enough people know it. This one is underrated. If you can find five developers for a given technology in your area, you have a choice and someone to cover for the rest. If three people in the world know it and they all work in Silicon Valley, you’re trapped.
It’s mature. A boring, proven technology that’s been around for ten years has its bugs ironed out, mountains of guides, and a community that has already hit the wall you’re about to hit. That’s an advantage, not an embarrassment.

The boring choice is almost always the right one. The excitement in software belongs in what it does for your business, not in how exotic the tool it’s written with is.

Who builds it: a team, a studio, or a freelancer

This is where you decide on risk and on how well you’ll sleep at night. Three paths, each suited to a different situation.

Your own team (in-house). You have developers on the payroll. Maximum control, people who know your business inside out, around for the long haul. The price: expensive and slow to get going, you can’t keep a single person busy full time, and half a year goes by before the team is assembled and humming. It makes sense only once software is the core of your business.
An agency or studio. You hire a company that already has its team in place. A fast start, multiple roles together (development, design, project management), and a replacement when someone gets sick. The price: a higher hourly rate and a little more distance from your business. It fits when you want the thing built well and fast and don’t want to spin up a department for it.
A freelancer. One capable person, the lowest price, a personal touch. The price, which has to be said out loud: a bus factor of one. If that person gets sick, leaves for a month in Asia, or lands a better gig, your software grinds to a halt and nobody else can find their way around it. Great for smaller things and prototypes, dicey for a system your revenue depends on.

Before you sign, ask yourself one question: “What happens to my software if the person building it disappears tomorrow?” If the answer is “nothing good,” your risk is in the wrong place.

You own everything: the code, accounts, domain, and servers

This is the point we’re most stubborn about at FRGTN, because we’ve seen how it ends otherwise far too often. A company paid for development for years and then discovered it actually owned nothing. The code sat in the vendor’s account, the domain was registered under their name, the servers ran under their login. When the relationship soured, they had nothing in hand. That isn’t a partnership, that’s being held hostage.

So from day one, ask for:

Access to the repository (your code, typically on GitHub or GitLab) under your account, where you’re the owner, not a guest.
The domain registered to your company, not to the vendor. The domain is your address; never let it out of your hands.
Accounts for every service (hosting, database, email, payment gateway) set up under your email, with the vendor merely invited in.

Do it as you go, not at the very end. Asking for access while things are running smoothly is routine. Trying to wrestle it back once things start to creak is a nightmare.

Lock-in and how to avoid getting locked in

Lock-in is the state where you can’t leave a tool even if you want to, because switching would cost you more than the whole thing is worth. There’s a bit of lock-in in every decision; the trick is not getting locked in by accident.

A practical rule: wherever you can, favor open standards and open source tools you could run yourself in a pinch. A database like PostgreSQL you can take anywhere. Your own code is yours. You can walk away from these things.

Accept vendor lock-in only where it’s a deliberate, real advantage, not out of habit. A payment gateway or sending email are services there’s no point building from scratch, and where the dependency pays off. The key word is “deliberate.” The difference between good and bad lock-in is whether you chose it or just found out you were in it.

How to spot a good vendor

You won’t spot a good vendor by their portfolio or by how many buzzwords they drop in a meeting. You’ll spot them by a few things they do from the start:

They ask about the problem, not just the features. A bad vendor writes down your wish list and starts coding. A good one asks why you want it, what it solves, and what happens if you don’t do it. They’ll often talk you out of half your ideas, and save you money doing it.
They show working software early and often. Weekly demos you can actually click through are the best insurance there is. You see where it’s heading and can change course before something goes off in the wrong direction.
They explain the trade-offs. Anyone who tells you everything can be fast, cheap, and perfect is lying. A good vendor says out loud what each choice costs and what you won’t get for it.
They’re happy to hand over the baton. This is the litmus test. Whoever gives you access, documentation, and keys without a fuss is building fairly. Whoever resists the handover is holding you hostage, and sooner or later you’ll find out.

You build software once, but you’ll live with it for years. Pick a technology that more than one person can keep alive, and a person or team that’s happy to hand you the keys. The rest is just craft. If you want a second opinion on either choice, get in touch over coffee. We’ll tell you straight what makes sense for you.