Get it right the first time.

An idea you believe may be able to change your industry and make you a fortune in the process.

You’ve probably talked with five, ten or even more “development agencies” around the world.

But there’s this … strange feeling you have that something isn’t right.

Something about the no-camera-having (or hoodie-wearing-basement-dwelling vibe) you get from the “experts” you keep on talking to doesn’t sit right.

And you know what?

We agree.

Your idea may have potential, but in the wrong hands, it’s worth nothing.

Actually, it’s worth less than zero, because you may well shell out a pauper’s ransom for a whole lot of nothing.

So before we get into the “good” side of engineering, something we know a lot about (insert accolades and awards here and of course applause) – lets take off the rose colored glasses for a moment.

—

A word of warning.

The world of “coding and development” is a cesspool of charlatans, sharks and snakes. And worst of all, incompetent development agencies.

There are 29 dangers that we have seen very intelligent founders get themselves tangled into and lose a fortune.

I’ll link a PDF in a moment that you can take with you into any conversation you have with any so-called “developer” on planet earth.

It will put you in the best position to make sure you don’t get taken for a ride.

The three things that are top of my list are:

1. You must own the source code.

Most founders assume that they will either have the source code (somewhere) or that it will be given to them implicitly.

I don’t mean contractually – I mean literally, you need to own the repository where the source code is held and you need to have 24/7 root access to that code.   

Why? 

Well, we’ve been doing this for a while, and a majority of our clients either get approached by venture capital or private equity at some point with a juicy acquisition offer – or they approach a PE group with an exit in mind.

That’s all good and well, but the entire deal lives and dies on the (presumed) fact that you actually own (and have access to) your source code.

Here’s why.

Your software (or app, or platform) once deployed is not tied to the source code.

It’s just the build.

The source code is used to make the build, but it’s not in the software.

You have compiled code – not source code – running live on your servers.

So you’re sitting there on a sunny Friday afternoon, that email comes across your desk, XYZ Ventures wants to sit down and talk with you about a 13x multiple buy out…

You’ve built this business to a point where it makes real financial sense to seriously consider their offer, so you email your devs out in Bangladesh.

You get a response on Tuesday (Monday was a holiday), and it reads (real email quote from an offshore dev team):

“We will release your source code for fully 5’000’000$ [sic] and can [sic] to schedule a call to discuss further”.

Your blood pressure goes from 0 to 100.

Are they out of their damn minds?

Or imagine it’s two years into your launch and you consistently get requested a specific feature from your users, but you want to have another set of engineers develop the feature.

You will need the source code.

Imagine the original devs go bust. 

You will need the source code.

There’s a hundred and fifty reasons I can give you as to why you need the source code… take my word for it. 

When you are developing your own IP – the IP is in the source code, not the fancy diagrams you have on your desktop.

(Download this PDF to ask anybody before making a decision.)

2. You must have crystal clear requirements.

No, I don’t mean vague nonsense like “sprint backlog”, “product spec”, “user testing loops” – that’s amateur hour.  Prototype schmoto-type.

You need real requirements.

A comprehensive SRS (Software Requirements Specification) is in order if you’re building real software. 

I don’t mean a proposal. 

I mean a legitimate document outlining the precise requirements for every platform, every device, every user, every feature, every workflow and every unspoken assumption that the application should perform. 

In plain english.

If your idea is worth a damn, you should expect that SRS to be at least 70 pages long, type 12 font.

Most projects start with a founder (you) who has a clear vision.

It gets handed off to a dev team who doesn’t take the time to study and learn about the project in any detail.

After a few “sprints” of development you end up with a Frankenstein monster with arms coming out of the back and eyes where the ears should be.

You’re seeing red, your development team is paid – bad.

Secondly, 70% of software development projects are late (according to Forbes), and I think that’s a light take.

If you do not have a clear understanding of what your engineers understand about the project, you are going to be frustrated with the outcome. 

Late or jacked up. 

Two bad options. 

Get water tight SRS – and make sure that doc is slammed into your contract.  Exhibit A.

3. Get your cloud architecture designed before you start coding.

It was 9pm on a Friday night in August.  I’m at a nice restaurant with my wife – it’s date night.  My phone is buzzing in my pocket.

Unknown caller.

I decline.

10 seconds later, “Unknown caller” buzzes back.

I decline.

10 seconds later, same shit.

I pick it up.

Hello?

I had to hold my phone a full 6 inches away from my right ear.

Why the literal f*** am I paying twenty-eight thousand dollars a week for my cloud?

Rough voice.  Sounds like a drill sergeant.

This is not a client.  I know all my clients.

I say, well, you’re not a client, so who are you?

The voice on the other end calms down a tad.

I was referred to you by (large client).

Hang on man, I’m at dinner, let’s pick this up Monday.

We ended up meeting the following week and what I heard was (yet another) insane story that is starting to become the rule today.

Turns out our lovely friend was actually a drill sergeant in a previous life, and he had hired an offshore company to build out his “app”.

His app was crashing nine times a day and users were livid (rightly so).

He then was slapped with a heavy hundred thousand dollar a month bill for his cloud, and his developers in India were completely unreachable.

Our cloud engineers went into his cloud and it was total and utter mayhem.  It took us about two months of complete re-architecting and refactoring of his cloud to get things humming – and today, he’s paying less than two hundred dollars a month. 

Untrained developers, especially those with nothing to lose (and when their credit card details are not attached to your cloud) can knowingly OR unknowingly set your cloud up in a very inefficient and low security way. 

Turns out he was getting DDOS’ed several times a week from China, India and Malaysia.  Turns out he had zero fault tolerance in his cloud.  Turns out he had no load balancers in his cloud. 

Out of the twelve page checklist we use to check security, performance and cost – literally zero of the items on the checklist had been checked by his offshore team.

Other than being interrupted on date night, this is something that I’ve seen more times than I can count. 

Don’t start development until you have a clear cut architecture for your cloud. 

Oh – and make sure that they are certified cloud engineers. 

—

Technical needs to be right.

The technical structure of your code matters.

The languages that are chosen can either be an F-35 or a flintstone sedan.

Let’s say your platform will have mobile apps in its suite.

Stay away from React Native and Flutter like the plague.

Yes, it’ll save your offshore team time.

They’ll take a shortcut and write one code base for Android and iOS, vs writing in Kotlin (good) and Swift (good).

But it’s going to cost YOU and YOUR USERS time, battery, CPU and user experience.

Do you ever use an app and your phone heats up?

That’s React Native.  That’s Flutter.

Hot phone = bad.

The phone is piping hot to the touch because the programmers are trying to make the device do what it was not designed to do.

The languages are non-native and require a ton of processing power. 

Yes, they are easy to learn, easy to code, they are built for shortcut kings trying to make a quick buck on unsuspecting founders.

The hard to learn languages are hard to learn for a reason.

This doesn’t stop at mobile.

When you look at web or native desktop applications, there are hundreds of similar cheap code languages that are used.

Do not settle for anything less than the best.

It’s a highly competitive market and users won’t care about anything other than does it work and is it fast as hell.

—

It’s not an app or software, it’s a business.

You’re not building software, you’re building a business.

Knowing this is what separates the founders from the losers.

From those who develop an “app” that never sees the light of day… to the rockstars that leave a lasting impact on their industry and are insanely profitable.

What does this mean in practical terms?

It means that there is so much more that goes into developing and launching successful software than “writing the code”.

The often overlooked side of the coin is the strategic (business) side of development.

What are users currently used to?

What do they expect from this type of application?

And – how can we guarantee that they are blown away by every aspect of the user experience and value prop of the app? 

What needs to be defined before development begins to make sure that the application will scale successfully, so when you reach your 100,000th download, a system wide catastrophe doesn’t occur?

What pre-launch strategy do you have in place to guarantee that your early adopters (a.k.a your first 5K) leave emphatic reviews, instead of 1 star tear downs (early reviews are life and death for a new application).

What engagement campaigns will be implemented to target users who downloaded the application but aren’t actively using the application?

What is your expected CAC?

How will you track your daily active users and compare that figure against your monthly active users (this single metric determines the virality and engagement of a platform)?

How will the first iteration of the platform (V1) be developed in a scalable and sustainable way so that implementing new features and versions in the future won’t necessitate a tear down of existing code or lead to interruptions in operations?

How are tertiary costs (API fees, etc) needed to run the application going to be tracked and mitigated?

These are just a few of the vital questions that need to be addressed before a single line of code is written.

Poor answers to these questions, or no answers at all, can lead to a situation where your platform is set up to fail before it’s even sent to production.

Yes, this means paying five, even six figures, a month in “maintenance fees” to your developer.  Not to mention grotesque “operating” costs that originate as a result of poor planning in regards to post launch costs.

Not to mention – your software is a business, it needs to be profitable, your engineers need to code with profit in mind.

Allow me to rephrase that.

Your engineers need to code with your profit in mind.

—

Here is your logical next step.

If you’ve read this far (and you’re able to stomach the truth I just shared with you), let’s schedule a session together and see how (and if) we would approach engineering your idea.

Apply here to get started.