| 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? |