How to Hire Software Engineers
You want to make software, you have no idea what you’re doing, and you somehow made it to this page.
Well, to start off, you’re in the right place. The world is better with more technical innovation, and you’re here because you want to move that needle forward, hopefully. If you look at the projects we’ve had the pleasure of building, you’ll notice innovation is in Axel’s DNA, and we’ve helped move a lot of needles. Some more painfully than others.
Below is the no-bullshit process for making software from start to finish. You don’t have to hire us to make your project, but you should read this guide from start to finish so you don’t get stabbed by the needle, so to speak.
Picking Your Software Partner
There is an entire army of “engineers” out there who don’t know ANYTHING. They’ll tell you EVERYTHING you want to hear, take your money, and build you shit. At least once a month, I get the following story. I hired (Insert random country) to build me X. They said it’ll take 3 months and cost $12,000. It’s been a year and a half…I’m $150k in…. It’s almost working, it’s just Google Maps isn’t loading the data…. Please help…
I take a sip of coffee and ask to see the code. 99% of the time it’s unusable. Unfixable. Bad architecture, built by idiots, will crash when you get 100 users on it. Have to redo from scratch. The reason I write this real story is to remember step number 1. Picking your software partner is a lot like finding your spouse. It’s really hard to find the right one that will fit your needs, budget, and goals. You might have to go through a lot of them to pick the right one, but when you find them, it'll make life a lot easier.
When you’re researching, ask questions and get answers that you can understand. What’s the plan? How is this going to work? If shit breaks at 2 am, are you answering the phone? (It can happen). If the answers are not as understandable and blunt as what you’re reading now… run. Don’t give anyone a dollar you’re not at least 99% comfortable with. You don’t need to understand the technical details of how things are built (I mean, your job is to ultimately sell or incorporate what we’re building), but you should be comfortable with the person giving you answers.
The Document That’s Not Egyptian Hieroglyphics
Software engineers are not mind readers. You’re more than welcome to have a conversation with us about what you’re trying to build, but until you write down details, those conversations are more or less pointless.
The document that you end up writing will serve as the first blueprint to get a plan of action going. Once you have a document going, you can get an idea of how much it’ll cost to build your thing. BUT PHIL, how do I write a document?
In any way you want. People often ask for an example document, and I used to send them one. Then they would fill it out and I was even more confused on what they were trying to build. Some people draw boxes on pieces of paper and send me pictures, some people make video recordings showing competing software and what they like/don’t like, some people write bullet points. Whatever is easier for you. You don’t need to write out what a login is. I got that. But you should explain what happens after a user logs in.
Naturally, when you write your first draft, there will be a ton of conversations / questions afterward. This is normal. At this point, you shouldn’t have paid anyone any money.
Designs - What’s it Actually Going to Look Like?
If you don’t know what Figma designs are, now’s a good time to Google them. You don’t necessarily have to use Figma, but Step 3 is all about drawing the blueprint. What is your app going to look, taste, feel, touch, smell like, etc. Designs should cover 95% of functionality, and you as a non-technical person should be able to look at designs and have a very good understanding of what is being built. If something doesn’t make sense, if it’s not clear how something will work… ask your developer (or designer) why it doesn’t make sense.
If you are just starting out a piece of software, you should do the designs before you program anything. If you have a piece of software and you’re adding to it, let’s say a mobile app to an existing web experience, it’s okay to combine some programming work with the designs as the first milestone.
Milestone Deliverables
Some places charge hourly; I’m not a believer in those types of places. A typical MVP (Minimum Viable Product) project can take anywhere from 3 - 6 months to build. The idea of paying hourly before you can hold any magic in your hand seems like an illogical process. Now, there are exceptions to this rule, but if you’re just starting out, step 4 is all about milestones. Your developer should be able to outline what is going to be delivered, at what time it’ll be delivered, and how much money you’ll need to pay at that time. We usually do a 50% deposit / 50% upon completion per milestone, but that’s what makes the most sense to us.
Here’s a sample milestone completion schedule that I wrote:
Milestone 1: Design + Login, Download interact with preselected area on Map offline (no data from server yet) (3 weeks backend, 3 weeks iOS + 3 weeks android) Completed in 4 weeks.
Milestone 2: Admin can draw area on map and assign to the Rep (3 weeks backend, 3 weeks iOS + 3 weeks android) Completed in 3 weeks.
Milestone 3: Create contact (Pin), Schedule, Contact by Street, Custom Tab in Contact Details (3 weeks backend, 3 weeks iOS + 3 weeks android) Completed in 3 weeks.
Milestone 4: Documents, Custom Forms, Search, Filter Full Completion (4 weeks backend, 4 weeks iOS + 4 weeks android) Completed in 4 weeks.
QA / Testing
At this point, you should have something in your hand that works from beginning to end. But that doesn’t mean it’s going to work for everyone. Different operating systems (especially in the Android world where there are thousands of phones) react differently. So now it’s time to test. Your development team/developer should have a QA. An individual whose sole task was to test before you got the app. You should make sure this person exists and that they tested your application before you share it with the world.
Afterward, share the app with everyone you know. Mom, Dad, Friends, and Grandma (if she’s capable of using a phone or computer). Make sure they use the app from beginning to end and everything works for them. There are services that exist out there that will also do QA testing for you. We don’t use them because we have 2 full-time dedicated pro QAs on staff, but I’ve read they can be effective. (Be careful as there’s a lot of data farming fraud here also.)
Once you’ve tested with QA and a bunch of people, it’s time for the finale, moving to production.
Moving to production
The developer at this point should send you a giant laundry list of things you’ll need to purchase. Your server (where everything will live), your 2FA services (should your app need 2FA), where to register for your Apple / Android dev accounts, etc. This is how to take “ownership” of your project. This also should be where the developer takes all the code they wrote and uploads it to a repository (GitHub or GitLab are the most popular, but zipping everything works also) and sends it to you. This is often called moving from staging (the developers technical environment) to production (the development environment for customers that you own).
Your project should be live on the app stores or you can go to your URL that you purchased and be able to use your application.