I’m starting a new business called Kynetx. As I go through some of the things I do, I’m planning to blog
them. The whole series will be here. This is the
eighth installment. You may find my efforts instructive. Or you may
know a better way—if so, please let me know!
I have a friend who has a way with words and has started his share of
high-tech businesses. I asked him his advice on getting started and
Dan said "Welp, you gotta get yourself a rude dog demo!"
What he meant is that you can't just start a business with an idea.
You've got to have something to show people. The demo doesn't have
to be too pretty (that's the "rude dog" part) but it does have to
demonstrate your idea and your ability to execute it.
For some applications, you might get by with a PowerPoint mock-up of
your UI, but I believe that to raise serious money for a high-tech
company, you need to have working code. Nothing else will do.
Paul Alstrom, a friend of mine, who's also one of the managing
partners of vSpring Capital
talks about nailing and scaling. VCs don't won't give you money to
"nail" your idea (although angels might). VCs want to put money into
proven ideas that need capital to scale. The more you have that
shows your idea is solid, the closer you are to securing capital.
Working code has heft. It turns ideas into action. Code makes ideas
come alive. Try telling someone about your idea. Then show them a
demo. Watch what happens to their eyes. I love how the lights go on
when someone can see something work.
Working code also instills discipline in the founding team and forces
you to "get real." Once you sit down, start cutting code, and making
things work, you suddenly start finding holes in your original idea
and ways to improve it even more.
This was written about open source projects, but I think it applies
to start-ups as well:
The best way to start an open source project is with code. Working
code. Hack away at home on weekends, maybe get a couple of friends to
help you out, and don't go public until you have something to show
people that does something interesting, and that other people can use
to build more interesting stuff on top of. You need this for a bunch
of different reasons: it establishes the original contributor's bona
fides in the open-source meritocracy, it shortcuts all sorts of
damaging debates about coding styles and architecture that can stop a
project before it starts, and so on.
Most importantly, though: working code attracts people who want to
code. Design documents attract people who want to talk about
coding. I've seen what happens on projects that start with no code
and a commitment to produce a design. Some of the procession of UML
diagrams were really well put together, but that's about the extent
of it.
Working code gives the rest of the people on your team something to
use for leverage in their thinking. Seeing things come to life is a
sure way to spark ideas.
What if you don't know how to code? Then you need a founder who
does. See my earlier post on why
you need a CTO. If you don't have founders who can cut code, you
have no business starting a high-tech business. That may sound
harsh, but I believe it's true.
The hard part of producing "working code" is defining "working."
How close to production does it need to be? For a "rude dog demo"
not very. It's probably more important that the UI be pretty than
the guts be complete. It may be running on your laptop and need a
month of work to get ready for production. That's OK for the demo
part.
Eventually you have two choices: throw it away and build the real
thing or morph what you've got into the real thing. For Kynetx, I've
designed the engine so that all the pieces are there, including a
plug-in architecture, and the difference between the production
version and the demo version is filling in the holes rather than
rewriting what's already done. That took more work, but we wanted to
progress from "rude dog demo" to "alpha customer ready" pretty
quickly.
I'm here to tell you: nothing made Kynetx seem more real than having
code we could call our own. Ideas are not assets, but code is. And assets
are ultimately what you leverage to make any high-tech business work.
Tags:
startup
kynetx
programming
cto
