

Ask HN: Lean & lowtech founders: How to choose a stack? - wjnc

Suppose you are planning a startup (buzzwords: lean, B2B,  computationally intensive: medium), but the founders are lowtech. Well I can program my way through some hacking challenges, but that's all very fragmented.<p>We've started out by sketching our product, doing product and customer research and are now in a phase where we make our design a lot more specific. What will be in our first offering and what do we want to achieve later on? Building a slidedeck, so to speak. (Fully knowing that when product meets customer, all bets are off.) Future phases would be grooming a first client and / or capitalist and starting the first (small) build.<p>That's where things get tricky: We are going to be hugely dependent on the quality of programmers, code and stack we select. On the one hand, you can burn cash like crazy getting a few high-stakes programmers on board. But that's not really on the table. On the other hand, we can take more risk, but save money, by building in parts via Elance. (This trade-off is only an illustration.)<p>Any tips on how to approach this phase?<p>-How do you choose a stack for a product if others are to build?<p>-Any good reads from people who've been there before?<p>-How do you minimise risks when hiring in a lean way?<p>-Are lean and nontech founders a no-go in your opinion?<p>Any thoughts are greatly appreciated.
======
pcowans
Can you say more about how your product is medium computational intensity?
i.e. what makes it more complex than your average databased backed web app?
Why do you feel that code quality is more important for you than for an
average project?

The architecture of your application is more than a one-off decision about
tech stacks made at the start, and I'd say that you really do need someone
with a long term stake in the company who's able to own this on an ongoing
basis. I don't know whether there might be ways to get an advisor on board to
do this rather than making a full hire.

~~~
wjnc
Good questions.

The complexity is not in the database, which will be tops several hundreds of
tables with thousands of rows by hundreds of fields. Peanuts, datawise. All we
need is dynamic updating of the tables, rows and fields throughout the system.
That's a small hurdle tops (unless we get the scale wrong ;).

The computationally intensive part comes from my background. I'd want to run
simulations over networks within our database. That easily beats normal
computational intensity. But the demonstration of this functionality is key.
Of course, lean could suggest making a faux-demonstration, but you still need
a basis of functionality in your first product.

Code quality is important both for me as a purist (don't laugh, but being
crazy for code quality is what I've learned in large firms in the last few
years, even as a non-programmer) and for our customers who will demand it
because of their markets. Especially if we would want to rapidly expand our
codebase (supposing we survive first customer contact), you need quality code
to scale.

In the basis it's nothing scipy + numpy couldn't handle, but there the OP
comes back: how can we know that we make the right choice in terms of
business, sustainability, affordability? That _I_ could build fragments in
Python says pretty much nothing. Next to that, my database knowledge is zero.
So we are still in the blind there.

Getting tech-knowledge on board is a good suggestion. But going from 2 to 3
founders is a big step. And who says we are not just moving the problem one
step ahead?

~~~
pcowans
So what is your background? It seems like you have experience doing something
technical, even if it isn't professional software engineering. Do you feel you
could code up a workable implementation of your network simulation in Python
which could be encapsulated as a component of a larger system using a mix of
technologies? Separating things out into modules for which you can (in theory)
implement using different stacks is generally a good idea in any case.

~~~
wjnc
Experience mostly in econometric and financial modelling + dabbling in code
for fun.

The workable implementation pretty soon baffles me on the database side.
Basically all I know is from flat data file or database upwards. I really
can't implement a system of cards that is expandable on-the-fly.

The modular approach is a good suggestion. It's what I got from the Trello
stack post as well [1].

But I'm still looking for a good heuristic to get those modules in place
(perhaps without someone extra on board).

[1] <http://blog.fogcreek.com/the-trello-tech-stack/>

~~~
pcowans
Okay, cool - so it seems like you do actually have quite a specific piece of
technology missing, but it also seems to me that this is an architecture /
technical design problem rather than just needing someone to code it up. It
also seems that it's pretty core to what you're trying to do, which to me
suggests that you really need a find a way for yourself or someone with a long
terms stake in the project to own this piece.

If you were able to encapsulate that part of you product (the simulation and
associated data store), would you feel comfortable architecting the rest of
the system (whatever that is - web interface, associated company website,
etc.) and bringing someone else on board as a contractor using fairly standard
technology (e.g. Rails / Django)? If you could do that it'd free you up to
focus on learning the bits which really matter.

Putting my two cents in technically, the way you're describing this makes me
think that it's not necessarily a good fit for a traditional RDBMS -
'hundreds' of tables of fields strikes me as an unconventional way to use
these technologies, but I don't know enough about the problem you're solving
to suggest what might be more appropriate.

------
rush-tea
hiring different developers to build different parts and then you join them
together is risky in a sense that the code is not uniform across all parts,
therefore it can be one part is efficient, one part is not.

hiring one developer to build them all is good in a sense because it's
consistent across the board. the bad point is that it's one developer only, it
takes time (vs multiple developers).

if you decide to go with multiple devs, choose a tech that is mainstream such
as Zend or CodeIgniter vs Ruby (while Ruby is getting popularity, but its pool
of devs is not as many as Zend).

------
julien_c
Where are you based?

~~~
wjnc
The Netherlands!

