
Startup Lesson Learned: Technology Doesn’t Matter - asp_net
https://thomasbandt.com/startup-lesson-learned-technology-doesnt-matter
======
simonswords82
As a developer turned sales and marketing person with a couple of products and
a software company boy do I agree with this post.

I have a friend that built and sold an online accounting app for £XX millions
(yep, that's two x's there) a year or so ago. He originally created the app
using classic ASP, as that was all he knew at the time. After a few years of
growth they started to build a .Net version of the app but it never saw the
light of day. Guess why? Because they were too busy growing the company and
ultimately selling it. And this is exactly the right approach. I'm pretty sure
with hindsight he wouldn't have bothered with the .Net version of the app.

It's way too easy to get bogged down in using <latest trendy frameworks>,
<trendiest latest NoSQL> or some other technical bullshit that doesn't
actually add value for your customers. I know because I've done it and wasted
far too many hours of precious development time.

So now whenever I'm reviewing the list of cards in Trello for the next sprint
on our app [http://www.staffsquared.com](http://www.staffsquared.com) I ask
myself two very simple questions:

\- Will this bug fix/change/new feature add new paying customers?

\- Will this bug fix/change/new feature reduce our customer attrition

If it doesn't tick one of those two boxes, it doesn't go in.

~~~
jnbiche
>\- Will this bug fix/change/new feature add new paying customers?

>\- Will this bug fix/change/new feature reduce our customer attrition

> If it doesn't tick one of those two boxes, it doesn't go in.

What about security fixes? Or secure coding practices? How do those fit in?

That aside, the attitude above seems like a good way to quickly get _deep_
into technical debt.

~~~
lmm
> What about security fixes? Or secure coding practices? How do those fit in?

I suspect that, sad as it is, a profit-making business probably shouldn't
spend much effort on those - the financial cost/benefit is pretty poor.
Customers are overwhelmingly indifferent to being hacked.

~~~
simonswords82
Well our customers might be but I'm definitely not. Even a sniff of a security
issue would be enough for us to drop everything and work to get it
investigated. A loss in customer faith for a brand or product is a tough thing
to restore.

------
josai
Well, that depends. I completely agree that needlessly messing around with the
cool-database-of-the-week was inadvisable and a waste of time.

But sometimes it's necessary to learn something new. I'm a rails dev who's
recently started what is basically a multiplayer game, and which will require
many simultaneous connections. I don't know if you know Rails, but it is
basically the worst possible technology to use for such a requirement.

It would be ridiculous for me to commence work on a project knowing I was
using the wrong tool for the job and that I'd have to rewrite completely if we
ever went above 10 or so users. So I'm learning and using something else, and
I think that's the right decision.

The trick is in being able to tell when to go with the tried and tested, and
when to jump into the new tech. That comes from experience, and you've just
gained some :)

~~~
bbody
I definitely agree with this. I even wrote a blog post expanding around this
idea! Thanks for the inspiration.
[http://www.mystartup.fail/post/110331046850/how-to-
choose-a-...](http://www.mystartup.fail/post/110331046850/how-to-choose-a-
technology)

------
bsdpython
There are two basic types of companies: (1) technology companies and (2)
companies that use technology. There is a gray area of course but you are
likely either one or the other. Most companies fall into category (2) so in
general your technology is entirely focused on serving the needs of the
business. Pick the best technologies to serve the business now and in the
future. The "cool new stuff" might be a good fit to serve the business but
mostly it's not.

------
lmm
You can't be innovative on the full stack. But you need to be innovative
somewhere, otherwise your company will fail just like your predecessors (there
are predecessors who failed in your space, right?)

Know what your USP is, and use technology to achieve that. Sometimes new
technology lets you do things that simply wouldn't be possible otherwise (I
spend a lot of my professional life cursing Spark, but the whole business is
built on dealing with a volume of data that simply couldn't be processed
without it). For other companies, the technology can _be_ your "edge"; if it's
a mature market with established competitors, being more willing to push the
technological envelope could be the thing that lets you offer lower prices and
higher quality; a couple of my previous employers have succeeded by doing
exactly that, in relatively "boring" industries.

But if you've got an innovative, experimental business model, you probably
don't need innovative, experimental technology as well (and vice versa). Know
which parts of your business are the innovation, and which parts are
commodity.

------
nadam
Technology does not really matter if you are not a technology company. Most so
called tech startups are not really technology companies. A technology company
is a company in which the most important added value is the solution to
nontrivial technical problems. You are a technology company if you create
video cards, VR headsets, rendering engines, game engines, machine translation
or speech recognition engines, etc... (These are difficult markets, as the bar
is usually very high.) You are not really a tech company if you create a web
app that serves web pages from a database however important user need you
serve or however successful you are. The problem comes when people want to be
technically creative at solving problems which need other kind of creativity
(usually business creativity).

------
current_call
He used a database he didn't know how to use, switched to another one he
didn't know how to use because someone said it was better, then switched back
to the first one, and then switched to another database. There's a problem
here, but it isn't using new technology.

~~~
300bps
To be fair, I think the OP realizes the mistake he made. His post is trying to
warn others to not make the same mistake.

I think the thing you're rightfully reacting to is the clickbaity headline.

------
collyw
Reading this post, it seems like the technology did matter. Go with the mature
option that is well know, rather than wasting time messing around with the
latest hipster crap.

~~~
TheOtherHobbes
It doesn't matter nearly as much as having a finished (if technically non-
optimal) product/service you can sell to customers.

The latest hipster crap is more likely to waste your time than something old
and established, but even then, choice-of-stack matters much less than 'Can we
finish this, and does anyone want to buy it if we do?'

The basic open source problem is that developing code for a 'Show HN' slot or
improving imaginary GitHub karma is not the same as building a viable business
idea around a web and/or mobile service.

There is no GitHub for business models. The ultimate karma comes from
customers.

~~~
marcosdumay
Except that the article cites tool selection as a major botleneck in "can we
finish this":

"Instead of focussing on your user’s needs and building a product that
everybody wants, you’re wasting your time and burn money by exploring and
introducing new technologies."

------
williamcotton
Sometimes that latest trendy framework actually is a much better approach.
Wanna know how you can tell the difference? Experience.

I used React for the first time when I started building the first version of
our MVP because I was familiar with and frustrated with every other front-end
approach in Javascript. Angular and Ember were bulky and slow. jQuery and
vanilla JS are god damned nightmares for complex interactive applications.
Because I have been writing rich client applications in Javascript for the
better part of a decade I could very easily assess the pros and cons of React
and realize just how great of a tool it was. The same goes for why I use
Browserify and why I still use Make (and not grunt or gulp, yuk) for my
builds.

The database I went with? Postgres. Redis is the only NoSQL tool in my belt
and I use it as basically a sophisticated caching layer, although now that
Postgres has such great support for JSON documents I might be fine without it.

I know for sure that there will be new tools in the future. Most will be new
versions of an old approach but implemented poorly. A few will be much better
and will have a major increase in productivity.

------
btbuildem
I agree with part of his argument - if you're figuring out the direction of
your product, it's more efficient to use whatever technology you're most
versed in - you don't have the time to spare on learning new things and making
all the mistakes associated with that.

------
jpatte
We had a very similar experience with FeatureMap. Started off with RavenDB,
got tired of all sorts of technical problems (migrations, map/reduce,
transactions, deadlocks, ...), quickly rewrote the data layer to use good ol'
Entity Framework + SQL Server, and voilà, all better now.

Looking back at this it seems clear now that the way we used RavenDB (it could
have been any NoSQL database) was not optimal and that most of the problems we
faced were a direct consequence of our naive/simplistic approach. From a
personal/technical point of view I don't regret the experience and I now have
plenty of ideas about how to better leverage NoSQL databases, but from the
business/customer point of view it certainly costed us.

------
freddealmeida
Technology does matter. It matters if you need it to achieve a certain feature
(recurrent neural nets demand a certain level of technology, for example).
Competing technologies, matter less. But every decision is debt forming. So
future-ready tech is better.

------
CmonDev
Are you sure?

[http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

Technology always matters.

Luckily you have already picked one of the best available: .NET ecosystem.

Also:

 _" And if you’re not building something completely new and patentable not a
single of your (potential) investors will ever care about the latest fancy
JavaScript framework, database, or programming language you’re using."_

How about Unity3D? Not new, not patentable, but Mono and C# was an ideal
choice. It mattered to them, it mattered to investors.

~~~
asp_net
You're right, my arguments don't apply to all kind of businesses. The same is
correct for Xamarin for example. But if you take JetBrains – no one cares how
WebStorm or ReSharper are built internally, as long as they do the job.

------
neverminder
I would not discard choosing a "new" technology (term "new" gets a little
ambiguous here), especially if it's been around for a few years and
preliminary research into it shows promise in regards to my project. I've seen
too many companies failing projects because of "When your only tool is a
hammer, every problem looks like a nail" situation.

------
pjmlp
Fully agree.

This is why on many projects I am responsible for, the team has to provide a
business value for the customer for new technology.

What it means in terms of $$$ for the customer to have the project adopt
technology X.

If it improves the revenue then sure, if it is only for playing with new tech,
then do it at home.

------
davemel37
This is so true but isn't limited just to your technology stack. Marketing and
sales are also prime candidates for chasing the latest shiny object...but the
fundamentals are fundamental for a reason and what you know best should be
your first avenue of attack.

------
Kurtz79
Um, the takeaway I get from the post is that Technology DOES matter, and you
should make sure it fits your requirements.

If anything, do not go for the latest/shiniest thing on the market, if you are
unsure it provides solid advantages on more mature, proven solutions.

------
aaronmu
Try making your experiments smaller. Lower the cost of failure. Don't stop
experimenting.

------
cbp
I mean, If you ignore the advances in engineering and computer research of the
last half century and just go with something new, different and unproven
because a friend told you so, can you really blame technology?

~~~
asp_net
No. I don't blame technologoy, it's all about the decisions I have made.

------
joe_momma
Technology can matter, if you know how to use it. From your story it seems you
guys went in blindfolded and just decided upon the technology on a hunch. That
is your fault, not the technology.

------
adrr
I disagree fully with his assertions. Technology stack will make or break a
company.

You're going to have pick new technologies, changes are happening. Are you
going to roll a one page app with just JQuery? Of course not. Are you going
build a 100TB datawarehouse on top of mysql? Are you going to build your
infrastructure off bare metal server? Even source control has changed. How
many people still use SVN?

Most important takeway from the article is keep things simple. Picking a
complex technology for a simple problem will cause you pain. Both in the
development environment and also in production.

------
graycat
While broadly the OP is fully correct, actually the statement

> Technology Doesn’t Matter

is over stated.

First, to be more clear, we need to consider what we mean by _technology_ : In
the OP, an example is some software _framework_ \-- for that, sure, especially
in the context of the OP, likely such _technology_ "doesn't matter". Why? In
terms from 100,000 feet up, we're still talking, say, _Turing machine
equivalent_ so that we should still be able to get the software written
without some particular framework. And, following the OP where it recommended
staying with the _technology_ the team already knew, the new _technology_
likely will not be much or any more effective, efficient, etc., at least in
the short term, for the project at hand.

But, I believe that the OP is missing an important point, one that, in my
opinion (IMO), your mileage may vary (YMMV), is too often missed:

First, for context, assume that the project is to solve a problem where a good
solution will be quite valuable but apparently also quite challenging
technically. Or, the nature of the challenge is, say, "How the heck is it even
possible to do that?".

Second, let's focus on just the technical part of the solution, that is, on
the challenge:

For this focus, let's have an example where the _technology_ very much did
matter.

Ike wanted some pictures. The U-2 reconnaissance airplane was too slow and too
low, and, thus, too vulnerable to being shot down, and he needed a plane that
would fly higher and faster, enough of both so that it would be much more
difficult to shoot down.

So, flying at 80,000+ feet at Mach 3.0+ should suffice. And, by the way, need
range 2000+ miles without refueling.

A challenge: Put two really large turbojet engines in an otherwise really
small airplane and can get thrust enough for Mach 3.0+, but some aerodynamics
says that at such speeds the air into the engine, as it slows down to subsonic
speed as needed by the compressor stage, can get so hot it will cause major
parts of the engine to overheat, i.e., burn out. There was at one time at
least one MIG 25 pilot who could confirm this point.

Relevant technology:

(1) There was a unit of Pratt and Whitney in Florida that considered such jet
engine problems and had a bright idea: At Mach 2.5+ or so, don't really need
the turbojet compressor. Instead, treat the engine just as a ram jet. So, take
the input air, let it bypass the usual compressor and turbine stages, let it
enter at essentially the usual afterburner stage, add fuel, and go. Bright
idea. And, yes, they made it work.

(2) At Mach 3.0+, even at 80,000 feet, the friction, etc., of the air gets the
surface of the airplane hot. So, need, say, stainless steel or titanium. The
MIG 25 used stainless steel.

Well, at Lockheed, Kelly Johnson considered the Pratt and Whitney engine and
titanium and designed and built a few dozen of the the SR-71s; Ike got his
pictures; and no SR-71 was lost to enemy action.

So, the engine and the titanium were _technology_ that very much did "matter".

And there are more examples from the past, and there may be more examples in
the future, that is, where _technology_ very much does "matter".

Not all possibly relevant _technology_ , even for software projects, is just
software frameworks, etc. as considered in the OP.

------
shawnb576
I find this argument very uncompelling. This product sounds like it never
exited mvp if sql server free was to be good enough. I'll agree that at small
scale there are lots of potential technologies. But it also makes me wonder
what was so challenging here that they felt they had to keep swapping around.
I won't speculate here.

However I disagree with the premise. At scale this absolutely matters.
Different databases have vastly different design goals or cap theorem
attributes. You'd better pick the right on or it'll impact your customer xp.

~~~
falcolas
> At scale this absolutely matters.

So worry about it when you get to scale, not before. Most products and
startups never reach the scale at which such basic technology choices matter;
their time is better spent growing the company (adding user features,
attracting new users, etc) than fighting with technology.

MySQL was never designed to scale to the levels which Facebook and Google use
them. And yet both companies are still using them today, even as the roles
they use them in diminish as better technologies are brought to bear.

Technology shortcomings can be worked around, so long as you're still in
business.

~~~
marcosdumay
> So worry about it when you get to scale, not before.

You are advocating people to spend man years of work just as their company
start to get sucessfull porting their codebase, instead of stopping a couple
of minutes earlier on to correctly decide what tools they'll need.

~~~
falcolas
> instead of stopping a couple of minutes earlier on to correctly decide what
> tools they'll need.

Based on my previous experience, I'm advocating exactly that. The reasons are:

1) Bikeshedding - Everyone knows that N technology is better than M
technology, even if nobody has real work experience with N

2) Starting with a new technology that people have only done side projects in
costs significantly more time than just a few minutes.

2a) Nobody knows what those costs will be before hand

3) By the time you actually have to spend those "man years", committing
resources those "man years" of effort won't negatively impact your ability to
reach new customers.

3a) This work will not be required "just as their company start to get
sucessfull", but at some point after that.

3b) You will most likely not have to do a full re-write all at once. Small
refactorings of the actual pain points is how its typically done (there are
plenty of examples of this in the marketplace today - Google, Facebook,
Twitter)

4) Premature optimization, YAGNI, DRY, etc. all apply to your technology
choice as much as they do your codebase.

~~~
JoeAltmaier
For some values of startup, this all makes sense. If you're trying to solve a
hard computing problem (not a social problem) then you have to write your own
code. Turns out open source rarely gets around to hardening their code.

The you get to decide - jump aboard some community and try to help them get
the code where you need it, or write your own. The community sounds nice, but
the thrashing there can add more work than it's worth - tracking
(incompatible) changes, arguing for your APIs and layering etc. Doubles the
job at least.

Then you write your own. Again time wasted but not how you think. With
examples of working code and/or a good idea what you need, you write it and it
works. But you spend the rest of your life defending your decision. Every new
hire naievely says "you could just have used node.js!" And you try to walk
them down the design points but its almost hopeless.

I'm maybe a little depressed about this right now. My startup just got
refinanced under the condition we use open source for everything, and write
our app as a web app. Which of course is a pipe dream, since our app does hard
things using carefully written low-level code, complex network strategies and
heuristics hard-won from a thousand customer issues met and solved.

But no! Chrome can do all that, for free! So I'm asked to quit being a not-
invented-here drudge and jump on board.

Anybody hiring?

~~~
falcolas
Ugh. Good luck with that... Maybe you can pull a "Breach" and only use Chrome
as your, well, Chrome.

[http://breach.cc/](http://breach.cc/)

------
santacluster
People who've made bad technological choices and then claiming "technology
doesn't matter" just because they fucked up are about as annoying as people
who always want to use the latest new shiny toys.

You just made the wrong choices at the wrong time for the wrong reasons.
Period.

That doesn't say fuck all about the next guy who may have perfectly good
reasons to either choose the next new bleeding edge shiny or go with tried and
proven old tech.

The final sentence is the worst advice possible. _Never, ever stop
experimenting_. Just properly separate experimenting from building.

And please stop lecturing other people because you can't keep that shit apart.

~~~
collyw
BY your logic I should be experimenting wit a load of NoSQL databases. Except
I can see that in my situation they give me precisely zero benefit over a
Postgres (except for some buzzwords on my CV). I can see that many of the
NoSQL key value stores are not much different from a Perl hash tied to Berkley
DB - I tried that 6 or 7 years ago - it can useful but fairly limited.

~~~
caente
No, that wasn't his logic. NoSQL data bases aren't the only tech that is worth
experimenting with.

