No-code sort of FTW

Back in the day when you wanted to build a startup you either needed to be or to find a skilled developer in order to get anything done. This hard requirement was one of the reasons why developers generally won the designation ‘rockstars’ on most ambitious startup teams; you simply couldn’t do without them.

You still can’t if you want to build something that’s solid enough to scale. But in order to figure out whether your idea has any merit at all, there is a lot of things you can do with No-code tools; software platforms that basically allow you to configure your application rather than code it from scratch.

There is an argument to be made that No-code tools have been around for years. Some say that Object Oriented Programming tools were essentially the precursor to the No-code tools of today with the UI being the main differentiator. Whether that’s true or not, I do not know, but fact of the matter is that the ability to ‘build’ applications have been democratized to people outside the hardcore developer realm.

And that’s a good thing. Because it allows more people to build more applications. And aside from the proportion of duds among them, chances are that more really cool applications – small scale, yes – will be built as a result of this. And that’s all good.

For founders it is amazing because it does three things: It solves the problem of having to find a hard-to-find-hard-to-get developer, before you can get anything done. It allows you to roll the sleeves up yourself and put your money where you mouth is and just get something out there to start getting some feedback from the market. And it allows you to get an understanding whether there is anything there there, before you go out and look for investment in order to build the full-blown thing, which also means you will need to give less equity up in order to get the investment, you need. In theory at least.

But aside from the lack of true scalability there is one obvious pitfall from betting on No-code platforms that founders should be aware of;

No-code tools shouldn’t be seen as an excuse for not being diligent about delivering real value to users and customers. It shouldn’t be an approach used on the ‘Fail fast’-terminology that IMHO has mostly been used as an excuse for not really caring about quality of what you offer.

What founders need to be mindful of is that it’s real people – potential customers – they are putting their solutions in front of. And with the competition in almost every sector out there being rampant, you as a founder can little afford to basically p*** off the same people that are going to be your bread and butter in the future. If you do so they will have plenty of other opportunities to get the problem solved, and they will – most likely – never look your way again.

This also goes to a point which I think is often sadly neglected, when we talk about startups and founders venturing out to do great things: It’s never about you. It is about the customers you serve, and the problems they have that you help them solve.

That is – front and center – the recipe for your startups success, and thus it would be helpful, if we got a bit more empathy for the customer into a lot of startup conversations rather than focus most of our attention on the founders and their credentials. Yes, they are crucial. But successful founders don’t exist without happy customers.

Why is this a relevant discussion in the context of No-code platforms? It is because with the ease of shipping also comes a responsibility to ship something that’s worthwhile. The good things about things being hard to get out the door is that you have amble time to reflect during the process and ensure that things work, when they go out, and that the things, you ship, are shipped for a reason. While it obviously slows founders down a bit, I think the process is overall healthy and has a net positive long term impact on both the product and the ultimate success of the startup.

For that same reason No-code platforms shouldn’t be seen as a shortcut to success but as a way to get more insights quickly on what’s truly worthwhile building in order for a startup to achieve ultimate success.

(Photo by KOBU Agency on Unsplash)

The daunting 1st prototype

The last week or so I have been busy building the first simple prototype of our upcoming app – a pre-MVP – for the MedTech startup, we’re working on getting off the ground. We will be getting it out there to get early feedback just after Christmas.

It is a daunting process.

Not only is it daunting to try to find the different pieces that when stitched together could form a somewhat crude but credible first go at what we will initially be trying to bring to market to create value for patients.

No, the most daunting part is that youre airing your idea(s) and inviting feedback from real potential users. And doing so full knowing that they can throw whatever they want in the form of feedback and criticism against you.

The prospects of getting feedback from people – or worse yet; hearing nothing at all because no-one will try it out – is so excruciating it can be a real challenge to push that ‘Publish’ button and get it out there.

But there is just no way around it;

If you never launch anything – not even a very crude, embarrasing prototype – you will by definition have failed completely.

So, reversely, by just getting something out there for people to provide feedback on is infinitely better and an infinitely greater step towards any kind of potential future success.

So just do it.


A roadmap of experiments

Currently, one of the things I am trying to do on our new MedTech venture is to build a roadmap of experiments to run before we get to the MVP itself.

Why am I doing that, you may want to ask?

Because I think it is super important to do whatever it takes to make sure that we can deliver some sort of tangible value from day 1 with our MVP. Nonetheless so because we’re in MedTech and because we’re dealing with a serious medical issue. We simply need to get it right.

But also because I think it makes overall sense as an approach. In fact I think it might even make better sense than to work on a more regular product roadmap at this stage.


Simply because at the stage we’re currently at there are so many unknowns and associated assumptions about where we might take this that the most robust roadmap, we can have, is the one articulating what we don’t know and thus need to find out more about.

But does that make it easier to do a roadmap of experiments than a more normal product roadmap?

Definitely not.

After all there are a ton of different experiments, you can run at any given point in time, and the trick is to figure out – or at the very least have an idea – which ones are going to give you most bang for the buck at any given moment in time. And where you take it from there – depending on how the experiment goes.

It’s a super interesting exercise in doing a blueprint for your activities while trying to make sure that you get to that ultimate goal of the experiment series; feeling pretty confident – on a data based basis – what should go into the MVP and hopefully set you off on a good trajectory for startup success.


Startup learning from ‘P.S. I Love You’

The Danish Heart Foundation just announced that they are closing down their youth-oriented dialogue website ‘P.S. I Love You’ a mere 3 months after launching it in May.

‘P.S. I Love You’ have been surrounded by a lot of controversy focusing on working with alternative, holistic thinking partners at odds with the foundations of the basic science, the foundation normally base everything they do on.

From that angle, closing the initiative down was a sure thing waiting to happen. And to be honest I don’t think many people will miss it now that it’s gone.

But there was another thing that puzzled me and says everything about why context is important, when you judge something:

Had ‘P.S. I Love You’ been a startup idea, we would perhaps by now be applauding it;

they launch with what they deem is a MVP,

they get the feedback,

they realize it’s not going to work,

and they sunset it.

Move fast and break stuff.



Fuck it, let’s ship it!


Turns out context is everything.


And again – as I have mentioned before:

When you are working with something related to peoples health and their medical condition(s) normal startup rules just don’t apply in the same way.