

Ask HN: What are some of the technical lessons learned at creating a start up? - pp33

I haven't been able to find much about the technical lessons learned.  I found lot of high level non-technical and marketing advise.<p>It would really be interesting to get feedback as to what technical things did some of the founders learn.
======
robfitz
I was a hacker edged into the biz/sales role (we had 2 other, stronger tech
guys on the team). So this is my perspective from watching (and building
pieces of) the tech over 3ish years.

Code quality matters. We did enterprise sales across several products, and it
got to the point where making minor tweaks to the older products to close a
sale was a complete nightmare.

You probably don't need to rewrite it. In most cases I've seen, re-writing
(e.g. switching technologies) is some sort of pathological denial about
delaying the admission that nobody wants the product.

The importance of scalability depends on your channel. We spent a lot of time
building in scalability, which was important for an advertising company (we
couldn't close sales w/out scale guarantees), but might not be important for a
word-of-mouth app.

Build an admin dashboard. A good one. You're losing countless weeks if the CTO
is a bottleneck for deploys and minor database tweaks.

I wish we'd used a modern web framework. I didn't write any of the server side
code, but our development felt particularly sluggish there.

Check for plugins and tools before writing it. Some of the stuff we wrote from
scratch was 2x commenting systems, 2x moderation systems, 3x analytics &
charting systems, and a widget sharing wrapper. Writing some of those in-house
was correct, but we did it somewhat compulsively.

Think long-term. We wrote some widgets in Flash, then switched to Flex because
development was slow. But for our ultimate vision, we needed <10kb widget
sizes, so we had to switch back to Flash a year later. Since the core of our
product was in that widget's UI, it was a non-trivial rewrite.

Write a stupid version of the UI first. A major UI overhaul delayed the rest
of a key deploy for ~3 months. Starting with a quick v1 UI which copied
twitter would have allowed the UI/UX guys to do things properly without the
server team screaming at them every day.

Shipping makes people happy. If you have an API, get people writing (&
launching) little apps which use it. Have them own those apps personally and
keep them on their personal githubs/portfolios. If you are playing in an
industry, encourage people to make 1-2 day apps, separate from your product
but wthin the same space. You'll stumble across some gold.

~~~
ig1
+1 for "before writing it" - it's easy to end up wasting time building stuff
which isn't a differentiator to your business, if it's not a differentiator
for you than see if you can use something off-the-shelf.

This applies for the operational side of the business as well, there's no
reason you should be running your own mail server, etc. today. If you're not
doing it in some unique way, figure out it you can get someone else to do it
for you.

