Startup Equity Distribution – an incremental approach

ezgif-com-resize
Equity distribution in early-stage startups is a slightly odd subject. Obviously at this point the startup is worth nothing – or less-than-nothing, if expenses are being recorded as debts on the future company – and who wants to argue about percentage points of nothing? Sometimes the whole subject is just ignored.
On the other hand, whatever the addressable market size of the idea at hand, the spectre of founders squabbling over enormous wealth is lurking somewhere in the subconscious of everyone involved, so it is equally possible to go the other way, and invoke complex calculation methods of one kind or another, however irrationally over-fussy.
While complex approaches are arguably better than failing to address the issue at all, a simpler method is more typically adopted: if there are two founders at the beginning, they are usually assumed to have 50% each, if three, 33 1/3%, etc – as in this Seedcamp agreement template.
If they add additional co-founders, there is a re-distribution by agreement, such that the original co-founders see their percentage ownership reduced, to ‘make room’ for the new partner. The process is repeated each time a new equity-holder is added (ignoring such things as special share types – usually considered as over-complicated at early stages).

I consider that there are several problems with this:

Continue reading “Startup Equity Distribution – an incremental approach”

Convergence product #1

I’ve written about convergence before, and here is NexDock, a slimline laptop which docks to all sorts of computing devices to provide screen real-estate and a physical keyboard.

It’s an IndieGogo project, 56% backed, with a month to go, so if you’re interested, check it out. It’s a cautious first project, but with large ambition. I’m going to back it, and I wish it well!

Developing a Digital idea without Developers

This is in many ways a companion piece to my previous post it started out as a version for LinkedIn, but rapidly evolved into something with a different emphasis.

The internet revolution has changed the landscape of our lives, and yet the disruption has only just started. Existing ways of doing business are largely unchanged from the way they were 20 years ago. Hilarious disconnects exist all over, when ultra-slick digital-only processes crash into messy physical transactions.

There is a reason for this. Coders like to code – they like the safe, ordered, complicated-but-not-truly-complex world of programming. And coders are the ones who feel empowered to invent digital businesses. So, of course, the early digital businesses are the ones that can be achieved with purely digital workflows, and don’t require the startup team ever to leave their own world.

Continue reading “Developing a Digital idea without Developers”

Using FilemakerPro as a RAD platform just got more interesting

I’ve mentioned before that we’ve used FPro as a type of Rapid Application Development Platform. Building a fully functioning prototype using this high-level (largely graphical) database application has allowed us, as non-coders (albeit with a decent understanding of how a properly architected database should be structured), to develop our therapy-smarter tool in an iterative way, without spending large amounts of money.

Another benefit is that the product we are using remains fully accessible to us at the architecture and data level, and is largely self-documenting. FilemakerPro produces human-readable graphical representations of its database structure as a standard report and the functional scripts are basic-like in their use of real language, and thus easy to follow.

What this means is that, for a team like ours, without coders, the scary step of commissioning native code from people whose work we will ultimately not be able to judge in detail is made much less risky. When we judge that the time is right to take the system to the next level – when we need it to go faster and handle more clients, we will have to get the thing recoded – and this will mean bringing developers in.

For startup teams without coders, this is a terrifying point. How do you find the right person? How do you choose which framework, which language, which platform, which architecture? How can you even begin to judge the recommendations you are hearing? How can you describe the features you want?

Continue reading “Using FilemakerPro as a RAD platform just got more interesting”

Announcing MyPhysioLink

MPL initial logo

After being a little coy about what I’m actually working on, it seems that it is time to come clean.

It’s been a slow-moving project, partly as I’m still having to earn a living doing architecture, and partly because my co-founder is even busier. But we’re about to step up a gear, both in time commitment and with an upcoming test-marketing launch, and so the time has come to make it public.

My co-founder is a physiotherapist. We’ve known each other for ages, but it wasn’t until I had an episode of frozen shoulder that I understood a/ how good a physio he is, b/ how important physiotherapy is, and c/ how ante-diluvian the systems around physiotherapy are.

Continue reading “Announcing MyPhysioLink”

Costing coding work – and the value of experienced intuition

OK, I’ve come to an impasse with what I’m doing at the moment – banging my head against a particular wall for a few hours too long.

Time to move on to another topic; pull out the mental list of all the things that need to be at least thought about in order to move our startup forward.

IP, MVP, business model, data protection, regulatory environment, legal structure, read more about Scrum/Agile, marketing strategy, logo design, data structures, UX prototyping …  …  … …  (…:::!!!!)

OK, here’s one: how much money are we going to need to spend on coding to get to a scalable MVP launched?

Big question! Cost estimation is a big deal in traditional bricks-and-mortar architecture, too, so I’m aware that this is not a subject to be taken lightly or fudged. A frequent and serious pain point in construction projects is when project estimate costs rise significantly AFTER the client is committed. Whatever else happens when this occurs, confidence and morale are dented, usually badly.

Construction clients want to spend as little as possible while statutory consents are at risk, and one way to spend less up-front is to do lightweight cost estimation (on the back of lightweight specification) and hope for the best. Of course, even if they have misgivings about these estimates, consultants are often unwilling to rock the boat at an early stage, not wanting to be the messenger that gets shot. Less scrupulous players have even been known to downplay cost risk until the client is committed, and then milk the situation (‘Oh, you wanted us to do the roof? Oh no, we never included for that. Yeah, yeah, I know you need a roof – rainin’ innit? Let me see what I can do for ya. Not gonna be cheap though – you wouldn’t want to skimp on a roof, wouldja?’).

So my approach to construction projects is almost always to convince clients of the value of making a larger-than-typical effort at the early stages to address all the likely risks – I’d rather have a client cancel early than go into something that is going to turn into hell for everyone. If they come up with another project in a few years perhaps they’ll remember me as that honest chap who saved them from getting burned.

So, can I do this with software?

It seems not. In fact, it seems not, big-style. Continue reading “Costing coding work – and the value of experienced intuition”

… eating glass, staring into the abyss

I was talking to my friend Mark van Harmelen of Hedtek (of whom more in a later post) about setting off on this path, and he gave me this quote from Elon Musk;

Being an entrepreneur is like eating glass and staring into the abyss of death.

This was meant kindly, of course; did I really want to put myself in this position, this level of stress?

There are two parts to a response to this; firstly, do I believe that this really what it’s like?

Continue reading “… eating glass, staring into the abyss”