What's your development process from idea to launch?

1

I’d love to have an insight into the development process of startups around here. How do you go from idea to launch? For us (Fonebase Labs), it is not like there is a laid down rule. We’ve only come to arrive at our current process through trials and mistakes over time. Needless to say, the initial versions of our products (Fonenode, Callbase, Writerack) never followed this process. The objective of this therefore is to:

  1. See if there is a standard process out there
  2. See how else it is being done/can be done
  3. See what we are doing wrong/how we can improve our process

I will go first.

Our team is a very small one. The current [active] dev team comprises 3 people - myself, a remote designer and an intern. Here is what our process currently look like

  1. Idea
    It all starts with an idea. We brainstorm about the why, the how and everything between.

  2. Mockups and Architecture layout
    My Co goes ahead to do the mockups while I layout the architecture - platform, tools, database structure, etc. I review the mockup later to finalize on final structure.

  3. Design
    We send the mockup to the designer. He creates the related pages (as images) and we review the process, giving feedback on color, image, layout, typography and other design elements. Once everyone is satisfied, he slices it (converts to html)

  4. Development
    Most times, the development is already ongoing before design completion. Parts that are not related to design (controllers and models for example) are being done. When the design comes in, it gets plugged in. Every collaborator forks the master repo and work from his fork. For every commit, he sends a PR which is reviewed and merged to the master. At stable stages, the master is pushed to a staging server for progress review. Once development is completed, the deployment is tested on staging. Once everything is ok, it then goes to the production server.

That’s pretty much it. One thing I’d love to hear about is the other ways code collaboration is done. Forks or Branches (https://guides.github.com/introduction/flow/)?

Tools we use: HipChat, Trello, Quip, Invision, Bitbucket and Mail

Related links (please share too):

http://scottchacon.com/2011/08/31/github-flow.html
https://www.crispymtn.com/stories/how-we-keep-shipping-code-several-times-a-day

12 Likes
2

This is a great topic.

Hipchat though :smirk:

2 Likes
3

I find chat distracting when I am working so I care less. Hipchat works (I can receive and send messages) and that’s it for me :relieved:

4

Interesting… Few questions… Do these ‘ideas’ translate to tangible business requirements? Do you formally document them? If yes, are they detailed - e.g. a functional spec? How do you ensure traceability to the final delivery for quality assurance?

2 Likes
5

@kehers Great topic!

This is a hard one to answer because like you said, you keep learning and refining from what works and what does not, so the next time is always different than the last in some way.

A little background on me. 4 Months ago I came back to start a software consultancy Blueport Software in Nigeria, up until then all my professional development experience has been in the US. I have worked for a huge software company with a lot of process to catch A LOT of development mistakes but I have mostly worked in small startups where everyone was competent and we used little process. So far I have seen there are differences and limitations in development in Nigeria. Some are culture of the workforce, consistent and cheap infrastructure (electricity, internet, phone) and also the ability to find developers you dont have to teach or “supervise” is harder. So I am going to try and list the process that has seemed to work for me from my experience please bear with me if something I note is not feasible in Nigeria. I hope I can contribute something that will be helpful to someone and I hope to learn from you guys that have been on ground for much longer.

  1. Idea
    Someone on the team comes up with an idea and shoots and email, IM, phone call to the rest of the team. This is basically a pitch and the most vulnerable part of the project. You have to sell why this is worth the time to build. The mentality of the receivers is cynical. All ideas are useless until proven otherwise. This does two things a) It saves everyone time b) If the team signs on, everyone is passionate about the project so motivation is high and you dont have to manage individuals (Everyone knows what is in it for them). This idea can come from anywhere in the company. As low as in intern or as high as the CEO. They all have to pitch.

  2. Refinement/ Mockups
    This is when the team has been sold. I find this part works best over skype video or physical meeting. We talk about what is the correct way to execute this idea. What is the MVP version and What is the Take over the world Version of this app/idea. In this stage no idea is stupid, basically talk without a filter and I always try initiate this in all teams at this stage. basically throw things and see what sticks, people usually have valuable things here because they bought into the pitch because something has already resonated with them, so this is the place to elaborate the vision. To make sure everyone is on the same page, in these meetings, informal mockups and architecture will be drawn and discussed.

  3. Design
    There is always a designer in the group, this is either someone who is a designer by trade or who has the most design sense in the group (depending on the company or team for side project). This person is fully trusted and after step 2, because we are all on the same page at this point whatever the designer comes up with we take. You can object to a design but you have to have a logical reason as to what is wrong with it. Nothing like “I like dark purple better” only objections like “The black background on the page is distracting and reduces the readability of the text… here are some suggestions”. this rarely happens if step 2 was executed correctly. (The design discussion can be done remotely or in person, doesn’t seem to change much)

  4. Daily status
    I have found that a check in on a daily basis, no matter how short or in what medium works wonders. Everyone is on the same page and if someone hits a problem the day before, there might be someone on the team that can recommend what to do or has faced the same problem before. I have worked in situations where me and the team where ALWAYS on skype. We worked remotely and rarely talked but it was like we were sitting next to each other. if someone noticed something weird or interesting they would just talk and the whole team can join the convo or mute it. It is def worth a try if you have the Gigs to spare :smile:

  5. Development.
    Similar to @kehers This is already ongoing immediately after step 2 (There has been only one company I have worked at where design was completed before one line of code was written). I find as long as the mockups are understood by everyone, it is ok to start coding. But yes you need to have some visuals on ground before you write code, lack of this has caused some VERY bad things. As of the repo, we do Branches if it is a significant feature, especially if it is a feature that touches multiple aspects of the product. If it is an apendage (feature that is stand alone) its the developers call. I find it is always good to let people code from where ever they want. I find that if a coder is comfortable it is easier for them to produce good work. So the team works on their own time (this is personal experience on side projects, all companies I have worked at were flexible but you still should show up sometime within office hours).

The two most important things I have found that make of break a companies process is Communication and Trust. Always facilitate good communication, people should speak up if they are in trouble or finding something hard to solve That means no shaming or blaming. Trust allows you to delegate work and know shit is gonna get done to the best of their ability. There is a high burnout rate if everyone is worried about everyone else’s work. The combination of the two make it easy for you to know what to worry about and what not to.

18 Likes
6

@niyoma

We try make “ideas” as detailed as possible. Ideas here doesn’t really mean a product on it’s own though. It could mean a feature or slight UX change. Product specs are documented in Quip and checklist itemized in Trello.

2 Likes
7

@adim86

Thanks so much for this! The daily status idea makes a lot of sense!

8

Agile methodology. Start with your idea. Create your stories (short description of what your going to build). Schedule a two week / three week sprint to work on your stories. U can have multiple sprints till you complete your stories. Daily scrums for progress and road block issues. Teams are broken down into complete components. Product owner, dev, designer, tester

2 Likes
9

This is interesting. At DevCenter we’re big fans of agile methodology, makes it easier for everyone to contribute meaningfully.

Design
Once everyone is onboard with the idea, the designer creates a mockup and user interaction is detailed. We discuss and agree on the final pick. This mockup image is then converted to HTML.

Development
Just like @kehers said development certainly starts on parts that do not require any UI to function. This is done tied to UI and pushed to repo, then everyone on the team can fork the branch and work locally. Once all commits are merged with master it goes to the test server, where we test and track issues. Once all issues are cleared and tested. It goes live.

Tools we use: Slack, Bitbucket, Trello, Skype, Moqups, Google Docs and Dropbox

2 Likes
10

Put up a wordpress site and get your first user!

11

Sorry, this is not related to the conversation.

5 Likes
12

@WaleF @CaptSpacely

How would you define agile methodology as related to how you work? Any special techniques (pair programming for example) you use?

13

I’ve used both Slack and Hipchat, and I must say, Slack is way out there. I typically don’t like HipChat for the following reasons:

  • Poor text / code formatting
  • Inability to edit chat messages
  • The UI is boring.
3 Likes
14

IMHO, It depends on the teams size and nature of the project. Am going to talk about some of the processes my team employs to build our stuffs.
NOTE
Things like the basic features an app should have like registration page, authentication service, landing page, feed system, database schema for common objects e.g User Schema. ,Tools depending on the language and project are already thought out, documented and fairly standard. So this step is most of the time not repeated. Rather we try and focus on the “new experiences/behaviors” that the new project requires.

IDEA CLOTHING/ DATA GATHERING
There should definitely be someone(team) in-charge of data-gathering, talking to third party organizations and generally the research necessary for the idea to mature. This need not be over emphasized. It is important to note that this step never ends throughout the development of the project.

Mockups and Architecture

This is mainly bootstrapped and depending on the app, we use common conventions here things that can allow us to focus on the core development e.g Using standard login templates. On Architecture, i think this can largely be dictated by the kind of stack you are developing on. For Instance, if you are developing for a Marionette/Backbone application, you won’t think long and hard about how something should be done. Everybody knows what the standard is and if in doubt the information is easily accessible. e.g multiple routers/ sub-apps, authentication service, …etc.

Development tools and workflows

Everybody uses git cvs tool and there are fairly standard git workflows that work well with teams of varying sizes such as ,

  1. A production branch
  2. A testing branch linked to testing server
  3. A Beta branch for everyone to pull and push to
  4. Once code is vetted by the powers that be , it is pushed to the testing branch.
  5. etc

That said , Firstly we want to make sure everybody’s dev engine(PC) is the same.
So there must be something for dependency management both frontend and backend[bower, composer, npm and maven],
js and css static analysers[jshint, jscsc, csslint],
watchers[watching dev files for changes and then performing some other tasks],
highly competent debuggers and loggers supporting file rotation,
minification and uglification tools to remove spaces in the build code and make everything ugly, testing[bdd or tdd], and finally
a continuous integration tools like Jenkins, gulp and ANT scripts. You gotta love you CI tools.

Outside your local engine, you should have travis cli set up together with the working repo for your team. I love this one in particular though it’s the tool i’ve least tinkered with.
Now instead of reviewing every other code added to code base, you can instead invest time in writing good test cases and allow travis to do it’s job. :smile:

Collaboration

For me it is gitter.im. In fact when am not on my IDE am on gitter.im knowing the in and out of some of the most complicated tools i use on a daily bases with some of the brightest people around the world including the team that developed the tool. Your team can have a private room on gitter.im and still be members of some cool rooms too. :smile:

Just ma 2 cents.

5 Likes
15

Excellent topic, had to bookmark it. A lot to learn from the responses. I’ve got similar process to most here perhaps just difference in tools. I’ll add some points which I don’ think have been mentioned. Hope it’s helpful:

  • Retrospectives: Like with most agile environments that have daily stand-up meetings, we also have a weekly retrospective meeting where everyone sticks post-it notes on a board answering 3 simple questions: what went well, what went wrong and WTF (things to clarify)

  • Story writing: Another thing that I’ve learnt in agile, there should be a standard way of describing features. Our Project Managers use Gherkin language. It’s business grammar so robust that even a machine can understand it.

  • Pairing: If it’s not a single man or distributed project, always emphasise pair programming. Switch pairs at lunch time.

  • Deployment: Goes without saying but never ever use an FTP client to manually ship code. Always use a Continuos integration tool. I use Codeship for personal projects and Jenkins in the day job.

  • Testing: Go automated with Selenium if you can. Manual testing will only catch the obvious visual errors, but automation can check for ‘unseen’ changes that can break your site and behavioural errors.

Tools:
Slack, Jira/Trello, Axure (zero reliance on Photoshop), Gitlab (Self hosted github; and it’s waaay better), Selenium Webdriver/CucumberJS, Codeship/Jenkins

3 Likes
16

Why will developers use Axure? If it’s the designers using it, How can you ditch Photoshop? where do you create your assets?

1 Like
17

The designers sent the creative for ideas (or new features) using Axure. Developers would often just annotate and get dimensions from there.

We actually did without Photoshop quite well. The site was built in a way that we didn’t need any image assets. Everything is CSS 3 and icon-font based, even the logo. Images are considered as part of content and added via CMS by editors so developers didn’t worry about that.

1 Like
18

Cool, thanks. I actually like the fact that Asos doesn’t have a responsive site. When you have the money, it’s the better thing to do.

19

Is your designer a freelancer?

20

Basically we do pair programming