I have this idea to turn Sixpy into a weekend startup. I have a full time job and a social life, so I can only dedicate so many hours a week to Sixpy.
Here are the commitments I expect from the team:
1. Equal founders
Everyone in on this from the start will get an equal cut of the equity over 2 years. This is supposed to be a very fast moving startup, so the first vesting period is at 6 months, and then you will vest more every 2 months after that. It’s a lot of hard work in a little bit of time, but if Sixpy isn’t launched in 6 months, we’re doing something really wrong. (Version 1 is NOT that big)
We can discuss pitching in some money to have a ‘fund’, or we can just start working (though, some money to get accounts like JIRA and Github–both cheap for small teams– or to get us together comfortable would be useful–but we can figure that out based on what everyone is comfortable with)
2. 16 hour work week
Everyone needs to commit to 16 hours of work a week. If we can do that, I know we can launch version 1 in under 6 months, with plenty of extra features just waiting to be developed.
3. 10 hour estimates
Ideally, we’d each complete at least 1 feature/task a week, and our estimates will be based on a 10 hour work week (to make up for our meetings and for downtime). Finishing early is a good thing because we can start on new tasks. Just remember, we’re committing to 16 hours per week, and we’re trying to get this thing launched in under 6 months, all while filling whatever roles need to be filled. It’s a team effort!
4. Daily emails
We should all spend a couple of minutes each day responding to the emails we receive within the team. This makes sure nobody is blocked and work isn’t piling up on anybody! Perhaps a required daily update email would help keep our minds on Sixpy for those 16 hours per week.
5. Weekly group meeting
It will be hard to get everyone to schedule all of their work time to be together, but something we can do is commit to just 1 meeting every week at a certain time that’s just 1 hour long (see why we only estimate for 10 hours?)
6. Presentations via wiki
Due to the small amount of together-time, if you have something to present, put it on the wiki and send out an email! Everyone is responsible for watching/reading the presentation (via #4), and taking care of their daily emails. (this should take little time if it’s done regularly!)
I imagine this team to be 3 or 4 people large.
So, the members? Let’s call them: JP, B, C, and D
Roles (in order of highest priority to lowest)
CEO – JP
Developer #1 - JP
Dev management - JP
Designer – (Slot most likely filled) B
Marketing - (Slot most likely filled) B
Developer #2 – ?? C or D
Systems Admin – ?? JP, C or D
Build Automation – ?? JP, C or D
JIRA/Wiki organizer - ?? JP, B, C and/or D
Of course we will help each other and fill whatever roles that need filling.
My general rule of thumb is: the person who is the most fit and the most available for a role should take on that role. There’s no reason person C should do marketing if person B is more fit and more available for it. Person C should fill another role if he/she is low on work.
Sixpy already has a good amount of work done! The foundation is built (server side and client side), and I’m quite proud of it.
The first week or two will be a little different depending on your role.
The designer will be working with me to better understand the app, then designing the few first pages that will need to be developed. In that time, I will also be setting up dev and test environments as well as getting automated builds to work. Before any dev work continues, everyone will be a beta tester of the current app. I estimate 10 hours for all of this. (So, that first week)
If I have a dev#2, that person can push on some of the server work needing done. I think the existing code provides an easy template on what to do. It’s a REST api, so it’s mostly (MOSTLY) a matter of writing SQL queries and keeping the code as neat as the existing code.
Then I continue building the iOS app! The designs will be ready so it will just be a matter of implementation at that point.
Code reviews will be required! This is really easy to do with a GitHub account, and I do not want to sacrifice quality of code. It will only bite us in the long run.
I think with the right team, we can launch in 5 months. I want to see this in the App Store, or at least in a VC’s hand, in that time (if not sooner.)
Stay tuned for part 2: manifesto.