So many times I’ve spoken with someone who is about to get their development done by someone offshore for a tenth of what they were quoted in Australia.
Usually, someone has told them that they can just go to Upwork/Freelancer/whatever and hire cheap labour. Seems easy enough yeah?
But I’m struggling to think of a single time that’s worked out well for someone in the long run. Actually… even in the short run.
Not doing technical things right from the start has a serious cost to it. It’s even got a name: technical debt.
Technical debt means that by choosing a cheap or easy way now, like monetary debt, it incurs interest over time to a point where, for lack of a better term, you’re screwed.
With development, you can’t really get something cheap or easy done now, and fix it later.
Sure, you can hire someone to make some changes, but it’s like building on sand. Sooner or later it’s all going to fall apart.
Problem 1: Trying to manage developers without technical knowledge
Years ago, we used a “cheap” company to build a software product. I put cheap in quotes because really they weren’t that bad. Somewhere in the middle of the range.
It was using a technology we weren’t familiar with at the time. We were strong in other programming languages, but didn’t know the proper way that things should be done in this new one.
Long story short, after massive email trails, several meetings and missed deadline, we ended up having to throw away the lot. It was a very expensive lesson.
Despite being actual developers, we STILL got burned.
If you’re not technical, it’s a lot worse.
Problem 2: Building on sand
“We need to rebuild it”
Almost everyone involved in tech projects has heard this from a developer. When I was still writing code, these words most definitely came out of my mouth a few times.
Sometimes, it is just because different developers have different ways of doing things. They rarely enjoy working with someone else’s code style, so they say something like this.
If that’s the case, they’ve just got to suck it up and get to work.
But other times, they really aren’t bullshitting you.
If the architecture isn’t right from the beginning, and more and more bits are bolted on, random little things start going wrong all over the place.
The app might get slow, throw errors or just be a general pain to use. Your users/visitors will notice, and you’ll start losing them.
Rebuilding is kind of like pre-emptively writing off a car. It’s not a wreck yet, but it will be. Buying a new one will cost less than trying to fix it.
It’s also worth mentioning that developers loathe working on systems like this. They know they’ll get the blame when it implodes.
The solution
There’s no magic bullet, but the best way to protect yourself from getting into these situations is to find someone you trust to help manage the tech side of your project.
That might mean:
- Hiring a local agency that has solid recommendations
- Bringing on a technical co-founder, or
- Hiring a technical consult whose job it is to make sure you don’t get screwed
It’s also really important to plan things out.
Many times I’ve been asked to estimate the cost of something with a one or two sentence description of what it does. That’s not going to happen.
Think about everything your tool needs to do, and get it down on paper. Who is using it? What actions can they take? Why do they need to do that? (These are called user stories)
Have an idea what it will look like? Draw that as well.
Then:
- Get a UX designer to create some wireframes so the flow through the tool is clear
- That same designer or another can make those wireframes pretty
- THEN a developer can start work
Both the planning and development process require their own posts. Stay tuned.