Thursday, April 25, 2013

Companeering: How to Architect a Startup

In this article, I describe my methodology for designing and developing startups.

First I identify my own needs. My needs are to aquire the abilities to do the things I would or could do with the right
tools, oppurtunities, and market knowledge. Focusing on the attainment of one or more of these three resources relative to a subset of business domains is the my first major decision.

Marketing First
I proceed by searching for clever marketing themes that apply to the primary business domain or a common theme that ties together the domains targeted, invoking the evils of premature optimization in the conjuring of a brand. This is the funnest part.

Funner still are naming the products and services the firm will sell or give away. The give away game is this: a maker of lightbulbs in a land where the people cannot afford lamps creates a customer with every lamp he gives away. Pervasive innovations are the only thing ethically worth paying up front for.  If it's simple, the task is to make it free and push foward the profit horizon for all players.  The goal is to steal the user base, and evolve once you have it. 

Execution, Meet Automation.
I need a program that understands my start up pitches and does the programming for me, that is, I need a programming language the
syntax of which my pitch conforms to, meaning once I have a pitch, I need a language definition file that matches my pitch.
There is a product idea.  Too hard to implement, moving on, but tabled.

Automate what you are doing.
What is the difference between any two start up ideas?
Whatever the differences , it would be a shame to repeat the same tasks for every start up idea.  Build enough tools for yourself, extract a restfull api, and you have a PaaS, a potential 2nd product to table for the moment.

Keep things discrete.
Whatever I code, will be accessed from a service, both in my architecture, and by my customers once my platform goes public.
Always work towards never repeating the same work twice.  Every node a module, every edge a service, and every graph an app.

Now for fun:

n/a =Firm Name
YardFence=Secure SSO
DirtBox=Online Repository
Sails=Bootstrap Project
SoilOnSails(SoS)=Web App Framework
LeafPile=Distributed Heap
LeafBlower=Distributed Queue

No comments:

Post a Comment