
A Failed SaaS Postmortem - jubjubbird
http://Mattlayman.com/blog/2019/failed-saas-postmortem
======
mblayman
I love the discussion about all this. For a bit of context, I kept the article
focused on the technical because that is the primary audience of my website.
There is a criticism that I focused too much on the technical side in the
article. That's entirely possible.

My choice to focus on the technical is because my lessons basically boiled
down to:

1\. Don't focus on the technical (#1 YAGNI, #2 Ignore software upgrades, and
#3 use the tools you know)

2\. Deliver something valuable to the customers as fast as possible.

In other words, I tried to say "don't focus on the technical side."

I admit in the article that the technical focus _of the article itself_ was
emblematic of why the project failed.

> Up to this point, I’ve written about the technical failings of the project.
> This is an emblematic example of why the project failed. I didn’t help my
> customers and was too focused on the technology.

Perhaps I was too subtle on that point.

Thanks for all the feedback. I've enjoyed reading the discussion.

~~~
dagav
Is this a postmortem postmortem?

~~~
mblayman
Ha! Yes, I suppose it is. :)

~~~
dagav
How do you think it went?

------
jahbrewski
> I didn’t help my customers and was too focused on the technology.

Somewhat ironic that your Postmortem is highly focused on technology as well
:)

But seriously, SaaS businesses are still businesses. I think so many software
developers think “I can build that!” about X and fail to realize how much of a
business has nothing to do with the product.

~~~
jjn2009
Given how often it is said that "build it and they will come" is an untrue
trope, you would expect people instinctively know to avoid spending too much
time on the build it part. I however am guilty of this myself so I can't
really blame the author and think most just tend to get lost in the
implementation phase because it's far too comfortable.

~~~
mitjam
I think the key is getting out of the comfort zone and do something completely
different. After a hard day´s work as a developer it is just too tempting to
continue developing, habitually, instead of doing inconvenient other things.

------
Crazyontap
This is not a postmortem of a failed startup, maybe a failed app.

The fact still is that to your consumer the software makes 0 difference. They
will never know if you're running php or python, serverless or cloud.

It's all a moot point until you hit at least $10k mrr or something. If you are
spending majority of your time on these technologies then who is working on
getting the leads, sales, seo, and the other little million things that are
equally important for success, if not more.

~~~
blaser-waffle
Bingo. The teaching and counseling crowd are non-technical for the most part
and they're not concerned with Django or Ember.

Independent college consultants also seems like a fairly niche market.

------
cddotdotslash
One of the craziest parts of this article to me is the sheer number of
technologies he picked right off the bat to implement the service. Datadog?
Digital Ocean? Wal-e? If he had gone with a cloud provider like AWS he
probably could have cut that list by 2/3 by just using built in solutions.

~~~
madamelic
Or a barebones box from Vultr or Linode then log errors out to stdout, slap an
email address on the page and there's your logging and error system.

AWS is massively overcomplicated for an indie SaaS business, and it costs way,
way too much.

You can have a box with plenty of room for $5 - $10 / month and it takes about
25 seconds to launch it.

I had 20k concurrent users with a $5 server and Cloudflare. Other people are
using serverless solutions, which drive the price even lower.

The author stated as much: keep it simple and boring. He thought he was going
boring for a SaaS, but he went way too exciting for what an indie SaaS needs.

~~~
spookthesunset
> Or a barebones box from Vultr or Linode then log errors out to stdout

So instead of talking with customers and growing your business you are busy
wasting your time installing a web server, database server, configuring build
tools, etc?

Getting root access to a barebones linux install is conceptually "not
complex". But that is only because it pushed all the actual complex stuff up
the food chain and into your head. A head that needs to be thinking about
everything _but_ how to configure apache or the load balancer or postgresql.

> keep it simple and boring

Installing a web server from a package manager and configuring it in a
repeatable way is not simple and boring. A single person startup doesn't have
the bandwidth to do that.

~~~
marcosdumay
Yes, you'll spend some 2 days setting all services, testing, setting backups
and alerts, testing again. Add another day if you want redundancy.

And then, every 4 to 8 months you'll spend some 2 hours making sure everything
is working right and up to date. If you get into another user-base class
(like, from 100 to 1000, or from 1000 to 10000), you will spend all those 3
days again.

Compare that with cloud services, where you'll spend a week up-front, and 2
days at random when something changes. But well, that comes with the bonus of
a much higher price and a slower development speed.

There is the safety to know that you can move between user-base classes
without any cost. You'll just be taken by surprise when it actually happens
and you discover that those 3 days are a rounding error compared to what it
costs to update your software.

~~~
madamelic
And building on barebones keeps all options open.

If you go big and realize an IaaS solution is right, great, you are ready to
go on to IaaS with no trouble

If you IaaS from the beginning, you've cornered yourself and have to build
your way out.

~~~
chii
How are these scenarios any different from each other?

You are not ready to go IaaS with no trouble if you've already built your own.
It's just as hard to do that as going from IaaS to your own custom
infrastructure!

------
tschellenbach
I think many people's corporate jobs don't prepare them well for the world of
startups. You tend to focus on optimizing some subset of a feature/product
etc. With a startup you need a much broader skillset and need to ship quickly.
So you need to master some subset of tools to be full stack and be able to
launch something in 2-4 weeks. Taking more time than that and you're just
setting yourself up for failure. The hard part is the feedback cycles on the
product, the marketing etc. So you obviously can't spend 2 years on what is
(or at least should be) the easy part of your business.

~~~
woutr_be
One of my colleagues (a backend engineer) was a CTO of a failed startup, he
always talks about it. So one day I decided to talk to him about his
experience, and it quickly became clear, that he as a CTO, was only focussed
on technical work, complaining about how engineers build solutions that
weren't scalable. How he fired people because they didn't write the code he
wanted.

When I talked about a startup I worked at, and how most of our backend was
written in Node.js, and about how we tried to improve our UI to make it more
customer friendly. He quickly dismissed all of it, blamed Node.js for failing
our startup, and told me customers don't care about a pretty UI.

It was then when I realised why his startup failed, at no point in time did he
ever talk about the actual product they were building, or what problems he was
trying to solve. He only talked about technical work, and about how that was
his main focus. He even thought making our UI customer friendly equalled in
just making it pretty.

------
ben_jones
> I didn’t help my customers and was too focused on the technology.

Great write up, though this gold nugget should be in a massive <h1> at the top
instead of at the bottom underneath a whole lot of coding talk.

The more I interact and learn from businesses the more I'm convinced founders
need to categorically stop writing code, buff up soft skills, and tirelessly
hammer the business needs at near complete expense to software development.
Yes some companies really are engineering first and need an engineer at the
top, but most don't.

------
omarhaneef
I don't develop web apps for a living but even I would have thought the
obvious solution is to first get v1.0 up in Rails/Django or whatever you know
and then try new frameworks etc.

Actually, if you want it to be a business, the first step would be just use
something else out there.

Buy > Customize > Build

It would have been interesting to see what his wife uses at the moment. I
think he could have given her functioning software by just taking her excel
sheets (for instance, if that is what she used) and just put them online with
Google, and connected them with Scripts and an interface with Forms.

After that was working pretty well, maybe he could offer to set it up for some
others.

Only after that would he selectively take pieces of the system and change it
to Django. So first, have the forms in Django talk to their sheets. Then have
their sheets dump into his reporting system etc.

~~~
karmakaze
The "Buy > Customize > Build" logic holds for supporting software. When it
comes to the core of your business, Buy is usually not an option and also
doesn't give you a competitive advantage. Also the effort of Customize can
often be greater than the Build path in short order. I've experienced this
with one startup that thought that it made sense to customize a Drupal CMS for
a bespoke experience with hybrid human/ML curation.

------
privateSFacct
I had a good experience doing many of the things the author suggests doing but
maybe didn't also as an evening / weekend fun project.

I built an app for a business. It was a very simple app - one or two input
choices / data but a somewhat complicated process from there (2-3 minute
runtime). High business value in the sense that it saved about 15 minutes of
staff time per invocation with hundreds of invokes.

But I didn't know how to build UI front end or do authentication. So I built
the app without any of that, you passed the data in at the command line, then
it emitted data out.

Great - I would run the app for folks based on the data they sent me by slack.

That worked great - happy users who gave me immediate feedback on the results
of the app, I was literally in the run cycle.

Then I discovered slack had a webhook/websocket system - instead of sending me
the data by slack, they could send the data to my app using slack. Perfect, no
front end needed AT ALL, AND authentication as already handled - all the slack
users in the company should have access. So slack called the CLI, then sent
back the result.

User count went up, and I deployed to AWS by just doing a git co on the server
by hand, picking up requirements.txt, then manually fixing the enviro issues
(even with a virtenv) by hand directly on the server and doing a snapshot of
the machine.

Very happy users - usage goes up.

More change requests, and deployment approach not great.

Finally I stuck a docker file on my machine because I HAD to, then set up the
CLI based deploy into fargate on AWS, which worked great for me - I would
develop, test on my machine, then run the three commands AWS gives to push my
docker into fargate. This still worked well.

THEN one of the integration partners changed, so I had to update things on my
setup, and discovered the Slack toolkit had changed and the recommendation was
to upgrade, which I did, which started an upgrade cascade. In my busy time
working nights and weekends - boom - the app was dead!

It was so boring not adding new features and making folks happy, but instead
redoing things to the "new better way" which made absolutely no difference to
anything I cared about. And every time I messed with one thing another thing
needed changing.

So I totally get that trying to keep an app up to date with libraries etc
might kill your productivity. It killed mine, and I waited as long as I could.

------
amitmathew
Hey, I can relate to this! I also started a company based on a specific pain
point in my spouse's profession. Although the best situation is to solve a
problem you've experienced firsthand, having a significant other be able to
give honest feedback on a specific challenge is pretty great.

I think the tough part that engineers have with these types of side projects
is that it's hard to assess how much time to devote to developing the product.
A lot of people will try to convince you to spend all your time talking to the
customer. I mean that's important too, but it's so much easier when you can
show them something that's great rather than just tell them about it. And
that's the thing - product development isn't most important thing to do in the
early stages, but it's still _very important_.

I wish there was more insight into why the project failed though. It wasn't
clear to me the project had to die. If he started focusing on customer
development, could the project have survived? Could he win back his wife's
interest? I was a tiny bit disappointed because his project is an adjacent
area to one of my company's products and I want to see it succeed!

------
hvasilev
I don't understand what the web world considers to be rapid technology change.
All of the products and frameworks that these developers are using feel like a
marginally better side step from the bare bones approach for small ventures. I
understand if you are a giant tech company why you might adopt one of these
technologies, but I have no idea why the common developers would be interested
in expanding their knowledge in this direction.

I would rather go in depth, strengthen your core, learn about different
paradigms, algorithms and structures. Why are you going into frameworks and
technologies that your employer is not forcing you to adopt? It is an
incredible effort to understand a technology and its specifics. What is the
value in this, it will be obsolete in a few years at best and odds are that
you will never use it again.

If large portion of your knowledge is frequently invalidated, how do you
people not burn out 5 years into your careers?

~~~
Scarblac
It's a constant treadmill.

Developers see people switching jobs a lot. They read Hacker News and blogs
and read about new frameworks. Companies are afraid all their people leave and
they can't find replacements. Developers are afraid their skills will go out
of date and they will be left behind when everybody is on Shiny Thing 2020 and
they have never used it. Developers jump for jobs that promise them they can
work with Shiny Thing 2020. Companies feel forced to rewrite things that are a
few years old in it because their remaining developers are clamouring for it
and they can't get new people in to work with tech from 2017. Repeat ad
infinitum.

I was out of web dev for a while in research, where we wrote code for machines
in C. Libraries were ten years old and worked fine. It was boring as anything.
I accepted that I'm addicted to the treadmill and went back to the web.

And finally there is the promise of the pot of gold at the end of the rainbow:
obviously the way we do Web development now is insane, but _one day_ we will
figure out how to do it _right_. And it will be beautiful, clean, extremely
quick to develop, every application will be a web app and it will ultimately
be boring.

I hope it happens the day I retire.

Also Django and Typescript are genuinely good tech and React is a clear small
step towards the pot of gold.

------
npollock
"At the start of the effort, I asked my wife questions about what she needed
and what would help her and other educational consultants like her. She told
me the things that she was looking for directly. But it took forever to have
something tangible to show her."

It's more efficient to get feedback on a few UI mockups than building a fully
functioning application. And if you get a positive response, it stokes
enthusiasm and momentum.

------
hogFeast
When he started talking about the tech, I could tell.

If you want to make money: make things that other people want. It is great fun
to tinker with the latest JS framework...but that is what you want to do, not
what other people actually need.

Btw, just generally, developers could do with understanding business better.
At most places, business is just something that gets in the way of fking
around with Haskell or whatever.

------
ericb
We just did something crazy. We _dropped_ the Ember app that was 3/4th's done
in favor of plain JQuery and Rails 6.

I'm just done maintaining two apps instead of one and all the hell that
involves. And the Javascript ecosystem can keep rolling that Sisyphean upgrade
treadmill with deploy dependencies and promises everywhere and I promise to
use it as little as possible. Because it is just a giant time suck. Tut tut if
you will, but we are moving twice as fast now.

No one sings of your glorious battles maintaining JS apps in the halls of
Valhalla.

~~~
Aperocky
You don’t need jquery either, native JS works just fine for most simple
interactions like startup apps.

Time to say no to npm and packages like is_odd that somehow are depended on by
thousands of packages. A sign of collective hysteria.

~~~
spookthesunset
> native JS works just fine for most simple interactions like startup apps

Oh god please don't. I worked with a startup whose "lead" (i.e. the person
with the most seniority, not the smartest) insisted the whole front-end could
be done with plain JS ("angular, jquery, etc... just useless bloat!!!" said
the lead developer). What resulted was the biggest rats-nest soup of
untraceable mess I've seen in a while. The only person on the team who
understood the system was the "lead" developer. Changes took forever. Bug
count was through the roof.

When you say "you don't need a framework", what you are really saying is "I'll
build my own framework". Because you _will_ be building a framework. And trust
me, your framework will not be as good as what is on the market. And when you
leave, all developers who didn't leave the company will rip all your shit out
and replace it with a "real" framework -- all while cursing your name under
their breath.

Your job at a startup is to get product-market fit. Not invent your own
framework.

~~~
sjy
Plenty of people create rats nests using frameworks, too. Would forcing the
“most senior but not the smartest” person to use a framework they don’t like
really have fixed your problems?

~~~
hnzix
A framework at least encourages a coherent pattern.

~~~
spookthesunset
Even non-framework people make frameworks. Just implicitly. At least a
marginally good “real” one probably had somebody think hard about it and a
great one has a community around it with plenty of devs that can jump right in
on your project. All of them will have better documentation and you can get
questions answered on stackoverflow. No such luck with the ivory tower anti-
framework bozo’s pet framework.

God I’ve worked for too many startups where some “anti-framework” bozo
declared frameworks as unneeded bloat.

Avoid these startups at all cost cause whoever hired the anti framework bozo
is also a bozo and whoever hired that bozo is also a bozo. Fish rots from the
top.

Not a good look for a startup with more important things to do than pushing
far-out technology agendas.

------
briandoll
The main point here seems to be that the failure to build a SaaS product is
blamed in part on the compounding technical debt incurred due to a fast-moving
software ecosystem and the effort involved in keeping up.

The point I think most people should consider instead, is that building an app
is not the same thing as building a business. Building the app is comparably
easy, once you've proven that you understand the market, your target buyer,
and have a unique insight/tool/solution to offer that you can deliver via
software.

If you want to learn a technology, by all means build an app. But if you want
to build a SaaS business, keep focused on building the _business_. The app, it
turns out, is the easy part.

~~~
throwno
The only problem with not caring about the technology, is if your solution is
trivial to replicate then anyone with a bunch of cash can come in with hired
gun coders and out advertise you. Hard to replicate technology gives you some
kind of a moat to at least slow down copy cats.

edit: Oh, I see, the guy in the article was just throwing together random open
source stuff not actually developing anything of value. Never mind.

~~~
briandoll
I'm not sure "hard to replicate technology" is a moat I'd often bet on, given
that by definition that does not deliver any specific advantage to your
customer.

User Experience. Developer Experience. Community. Those are moats you can bet
on primarily because it takes so much dedication, expertise, and work. That's
not easy to buy.

~~~
throwno
>User Experience. Developer Experience. Community.

But that's what I'm saying. If you find some solution to a problem that's
making decent money, some guy with big capital will just come in and "fast
follow" you with better user experience and advertise the shit out of it until
they have a better or at least more active community. Like suppose this guy's
admissions scheduling app actually started making money. Why wouldn't some big
player like Pearson just come in and roll him? They can easily hire a bunch of
guys to copy what he's doing and then leverage their existing relationships
with the education industry to lock him out.

~~~
mrmanner
While Pearson have the advantage of some connections at universities and in
the education sector, they also have the disadvantage of being a large and
slow organization. Hiring 25 people won’t get you a better product than that
lone wolf has, unless you (the one hiring the 25 people) have the vision and
understanding of what those 25 people are going to build.

And from what I’ve seen of Pearson, I highly doubt they have a clue. Their
existing business survives due to market inertia, but they’re very far from
delivering quality products.

~~~
__jal
Education is a very "enterprisey" market in which the purchasers are not the
users, who are essentially powerless.

Pearson doesn't need to deliver quality, they need to deliver functional +
whatever sweetener on the rest of the contract to keep out the competition.

------
lukax
For one project we did recently we also used only Django and its templating
system despite all the fancy SPA frameworks (React and Vue) we used on other
projects. This project was a CRUD app with a lot of master/detail pages
(tables and forms) and very little dynamic content.

We used StimulusJS[1] for adding dynamic stuff like table sorting, filtering,
pagination, form validation and uploads. All tables were rendered server side
(including changing pages, which just rendered the table body on the server)
and we just used Django Model Forms. Using StimulusJS allowed us to structure
the JavaScript code into modules and controllers which allowed us to reuse
code on frontend without any complicated frameworks.

There was no requirement for a REST API so doing a SPA would be a waste of
time.

[1] [https://stimulusjs.org/](https://stimulusjs.org/)

------
encoderer
It’s very hard to manage your time as a nights and weekends project. You
should consider it a skill of equal importance as coding/design/marketing.

I’ve written about it here: [https://blog.cronitor.io/the-jit-startup-
bb1a13381b0](https://blog.cronitor.io/the-jit-startup-bb1a13381b0)

The main takeaway:

"If you’re a software developer it’s especially tempting to justify spending
more time on your software. You’ve worked with tangled messes of code in the
past and suffered through others’ poor product choices. This is your chance to
“do it right” from the beginning, but that’s a trap! Never write a line of
code today that can be put off until tomorrow. Focus exclusively on the
essentials, and handle everything else over a support channel."

------
tnolet
I'll go out and say it. Most Indie SaaS developers don't really __really
__want to start a business.

They might want it consciously and convince themselves of this fact, but sub
consciously they are making the wrong choices, optimizing the wrong things,
digging their own grave.

The moment things like customers, prices, marketing, money, taxes, lawyers,
incorporation, accountants, employees — all SUPER normal things in any
business — come around they freeze up. Safer to upgrade Bootstrap.

~~~
spookthesunset
I was guilty of this. Spent far too much time optimizing database indexes and
far too little time actually talking with customers and validating new ideas.

Technology choice is the least important part of a startup. Pick what you know
and roll with it. Make sure the first developers you hire "get" startups and
aren't in it to tinker with their pet projects or push some bozo agenda (eg:
don't use js frameworks because.... they are "bloat". don't use third party
libraries because they are "security risks". don't use the cloud because RMS
said not to). Developers with strong "unorthodox" opinions about technology
are toxic to startups.

~~~
tnolet
The "bozo agenda" is a great point about early tech hires. I bumped into a few
over the years and they can totally kill your dev team and young business.

~~~
spookthesunset
Tell me about it. It is even worse when they are protected by the founder, who
is either non-technical and considers the bozo a "rockstar" or is technical
and brought the bozo in because of past relationships (friend, coworker, etc).

The bozo gets protected by the founders and all future developers have no
career path, no say in the technology, and get to swim in the sea of an
opinionated hot garbage codebase.

People who leave big companies for startups to escape the politics eventually
get a rude awakening. Startups, especially very small startups, have a whole
different set of frustrating politics. Not even sure which is worse to be
honest.

------
Disruptive_Dave
While I recognize the audience and the writer's background, the fact he spent
the first 75% talking about his stack is indicator #1 his "business" wouldn't
work. Just cause you can build a boat doesn't mean you can sail.

------
rajacombinator
Not convinced he learned the lesson. I see nothing about why the product
failed just a bunch of blah blah about tech stack choices which are almost
100% irrelevant for a pre PMF product.

------
enraged_camel
I disagree regarding software upgrades.

On the one hand, it is true that unless you have customers, what you have is
just a hobby, and you should refrain from stuff that distracts you from
solving the core business problem.

On the other hand, certain things become a _lot_ harder and a _lot_ more
complicated once you have users, because the stakes are higher. So there is
value in making sure you're fully upgraded and patched up _before_ you cross
the Rubicon, so to speak.

~~~
threeseed
I tend to agree with this.

It's easy to do a database migration, library upgrade and breaking changes
when you have zero data and zero users. But once you're past that point then
even a minor database migration can be a week of work.

------
tunesmith
So many big frameworks are oriented towards big companies and many hands, and
I understand why, but I wonder if there are examples of frameworks that are
designed for single authors, that are designed to stay simple and change
slowly, like an LTS release. Like, I still know how to write html hooked to
php scripts, but once you want a javascript event model it seems like React
swallows everything.

~~~
irq11
Rails works really well for single engineer projects. It’s just not the
hotness of the moment.

It’s pretty cringeworthy to see someone parroting the “use boring technology”
line, then immediately running off and making an SPA for something
that...let’s be real...could probably be done in a week or two by a single
developer with a Rails install and little else.

~~~
x0x0
another vote for rails, bootstrap, and a sprinkling of jquery.

------
jiux
> 1\. Don't focus on the technical (#1 YAGNI, #2 Ignore software upgrades, and
> #3 use the tools you know)

Adding to this with what one can focus on...

Start with an empty mind identifying your customers’ or audience’s problem.

Then answer with the technologies that make the most sense to solve it.

------
edoo
I've been doing firmware for the better part of a decade and I used to do PHP
MVC web stuff before that for a megacorp. They used Yii which had
ActiveRecord. You could have it scan your entire db and generate all the
models including relations, then abstract from those models for the business
logic. Any db changes... just re-run the generation. I can make a complex 15
table database and all the models in a few hours and jump right into
productivity. Seems weird people are still going through problems with this
today.

------
jlis
Oh boy I can relate to a lot of things in this article. Like switching
technologies back and forth, focussing too much on polishing instead of just
delivering the damn thing.

You just think "ah, let me get this perfect and the customers will flood in
automatically", but that's just wishful thinking.

In my case I think it relates to a fear of launching public and being
criticized and judged.

I'll do it better on the next launch.

------
remotecool
You don't need half of these services/tools. Especially when. You are building
an MVP.

Your first version should be very simple with very few layers.

~~~
threeseed
I couldn't think of any of those that aren't needed except for Segment. You
definitely want monitoring and metrics in place before you launch otherwise
you won't be able to figure out issues with your product.

And in the early days it's all about fast iterations.

~~~
bpicolo
Monitoring and metrics don't matter at launch when your scale is at most a
handful of b2b clients. For an API-as-a-service? Maybe. But humans will be
quick to let you know if they hit issues. More importantly, if you're
fulfilling an important function for them, the number of 9s in your uptime is
the least of their concerns.

This is exactly the trap the OP fell into.

------
tekkk
An interesting write-up Matt, thank you for that. It validated some of my own
observations of how businesses are actually built and although it didn't even
get off the landing ground, it was nice to read even as a technical report of
what not to do.

While I do not have experience of running my own start-up, I have with keen
interest seen people build start-ups around me and by far the biggest leading
factor to their success is the team. The team is everything. Sure, you can
maybe sketch up a decent app and maybe sell it to couple businesses but then
what? You'll be over your head with work and maybe hire some of your friends
and if things work out well, it could work. But why didn't you hire those
great friends then in the beginning? Why didn't you cofound the company
together?

See there's something about people working cohesively in groups that just
outmatches anything that a 1-man team could do. Now I'm generalizing here a
little, but the fact of the matter is that alone, without your peers to
constantly revalidate, build and improve your business-idea, you'll be miles
away from those teams that are actually doing it. And if the idea sucks,
you'll just pick another one. It's just that easy. When you have a group of
friends who are that driven and capable as you are, it's only matter of time
when your start-up actually takes off. There are so many would I say
"mediocre" folks running perfectly good companies because they had great co-
founders, had those social skills and networks to grow larger and eventually
it became self-sustaining.

Hmm it's still a bit hard to pinpoint the exact reason why I think it is so.
Maybe if I put it in this way: you are creating a machine made of humans. In
the heart of it is the dynamo, the moving force. That is what keeps it moving.
And even if it would one day be gone for some reason the machine will keep
running, by its inertia, for who knows how long. But to build this starting
unit, this dynamo. It is what starts this whole process.

In this case, sure you made the wrong calls with your tech choices.
Understandable. But if you had a good co-founder, or even better a good team,
I'm sure you'd have together figured out in no time that this was a dumb way
of doing this, and picked up something you knew and were able to execute with
quickly. It could have been just jQuery and PHP5 and be just as fine as any
new framework (with a massive technical debt waiting, sure) but that alone
would have not killed your start-up.

------
sky_rw
"Software as a Service" implies a business. I don't think this was an attempt
to build a business. If it was in some skewed sense an attempt at that, then
the entire post save for the "Ignoring customer development" section should be
deleted.

------
ykevinator
Great article thanks for sharing. I would love to hear the business side. How
did you get leads, what was your sales process etc?

