I’ve worked with close to 200 startups over the years. So I’ve seen a lot of stuff. Some of the get-rich-quick managed to get broke even quicker. And others saw great engineers leave behind a clunky maze of an architecture with little or no documtation.
Join 35,000 others and follow Sean Hull on twitter @hullsean.
Here are some thoughts on what to be mindful of…
1. Keep the stack simple
Are you asking yourself questions like these:
o if we build x,y,z it will save us time later
o we need kubernetes because everyone is using it
o let’s deploy on Amazon’s Cloud, everyone is there
If so you may have sidestepped keeping the stack simple. If you are building a proof of concept, mvp, chances are you do not need to build all the bells and whistles.
Relentlessly apply the discipline to keep things simple.
Read: Are pioneers and process people different breeds?
2. Use boring technology
You may be tempted to use some exotic new language. I know this new framework solves all the problems that have come before. No!
Let someone else live on the bleeding edge. I’m not suggesting to use COBOL, though there is still a surprising amount of that still around. What I’m saying is 5 year old tech is *not* legacy.
Not sure? Do a quick search on a job site for the language or technology. How many candidates do you get? If they are rarer you will pay more. And replacing your genius developer will be even harder.
But boring technology is not just about finding talent. It means many of the problems have already been solved. This is huge. There are proven ways to implement with the tried and true.
Related: Why is Martin Weiner special?
3. Beware of sharks in the water
Sharks can come in many forms. Investors that want to take 50%, a google or an Amazon that could rearchitect your solution in a week. These are real and present dangers.
Let’s not forget overspending on co-working spaces, and hidden costs around benefits, and surprising fees on your data or aws bill.
Related: How can 1% of something equal nothing?
4. Outsourcing – trust but verify
You may be able to hire one or two devs locally in new york, but if you need a larger team, you’ll likely look to outsourcing. There are tons of talented and brilliant engineers worldwide. So it makes sense to leverage this.
Beware though of handing all control to a team outside our shores. That’s because if you stumble into a legal trouble, you cannot use legal methods to resolve them. Some examples…
o what if you lost your aws keys and the outsource team holds you hostage?
o what if you are hacked, and the outsource team abandons the project?
o what if the outsource team tries to steal your IP?
I’m not suggesting here that outsource teams are any more likely to do these things than some firm locally. I think these events are rare in business. But if they happen local you can use the levers of the justice system to resolve. Remote may not lend to that.
Related: The art of resistance – when you have to be the bad guy
5. Relentlessly manage time
Your time is going to be short, and you’re trying to do the impossible. Use the tech wisely:
o use monitoring systems to alert you – no need to manually check things
o beware of slack and email – as they can destroy productivity
o automate where you can see real benefits
o keep the architecture simple!
o network for hiring people
Related: Is maintenance a forgotten art?