Our Software Development Process

Q:  Talk to me about our own software development process.   

A:  As with most things, they start in sales.  So, somebody might come to us and say hey, I’ve got this idea, I want to make it a reality, and we go, okay, cool.  We start a conversation, a dialogue of what are you looking to do, trying to figure out right away are we going to be a match?  Is it worth us continuing this conversation? Do we have the skillset that you’re looking for? Do you have the kind of personality traits as a human being and as a business owner that we also work well with as a company?  And so it’s this initial thing in sales of like trying to find, are we a good match at least to have this conversation. Assuming that went well, we then move to a workshop phase and so what that entails is you then come to us, or we go to you, and we take your idea and we put it all over the room, and we break down every small aspect of it, all the little details, and try to extract everything out of your head, so that it’s all out on the table.  I want to know, if I’m a customer coming and visiting your site, what does my journey look like. If I start on the homepage and you eventually want me to purchase something, what’s the journey for me going from this homepage to hey, you just bought something? Fleshing all of that out. If you’re an admin of this system, how do I see that order come through? Or reporting of I want to see how well this user journey is being tracked, I want to see those analytics.  And so breaking down all those different pieces as part of that workshop. And what’s key about this workshop is it’s still non-binding, we’re still dating, we didn’t decide that we were going to get married right away, we want to date a little bit and like you might be a good match and maybe we’re a good match too, but let’s go on a couple dates and see if it works out. So this is kind of like that second date. And at least at the end of this date you get to walk away with an idea of what you’re building, a fully fleshed out user stories, a good estimate of time and dollars that you’re expected to spend, whether that’s with us or with somebody else.  A lot of times we even build out prototypes, kind of clickable UI prototypes that you could even take to investors or other people, and say look, this is exactly what I’m looking to you building.  

Q:  So, it sounds like first step, vetting, let’s call it matchmaking.  Second step now where we’re at discovery, learning what they want, and then producing the assets or deliverables that will help them get there, or at least put shape to what they’re doing.   

A:  Yeah,  and then assuming that all goes well and we think it’s a good match and you think it’s a good match, cool, let’s keep this going.  And so that’s when we get a project signed on, we schedule out, we say hey, we’re going to get going on this date, based on our user stories and timeline, that has an estimated launch of around here.  There are certain things that can obviously change that, if all of a sudden partway through some of your needs change, and again, kind of pointing back to the whole agile approach, if we need to be flexible and move things around, most of the time we try to work it in a way that doesn’t extend timelines, but sometimes it does.  Sometimes it might shorten timelines. But the next step is obviously getting into those development cycles, as well as working with design. So, in this workshop, we’ve also modeled out kind of a lot of your data, so our backend teams are able to go and start building out these data relationships and modeling everything from a software perspective, while the design team is going and working with you to figure out how can we take the prototypes that we’ve built and turn them into a great user experience.  

Q:  Okay, again, just re-summarizing to help keep the train going.  Step 1, Vetting. Step 2, Discovery. Step 3 let’s call it Engagement.  Step 4 is then project planning. Step 5, now we get into this build, whether it be design, whether it be development.  So, walk me through maybe some of the more software development cycle or the process as it might relate to the build.  

A:  Once we get into the actual software, we’ve got frontend developers working on the user interfaces under UIs of the site, we are taking each story that we went and created in the workshop.  A user story is just a description of what a user in the system, that could be a consumer, an admin, or whoever, is able to do within the system itself. We provide a time estimate of how long we think that will take, as well as whether we think, hey, this is critical, you can’t launch this app without this feature, or we think, hey, this is a medium priority, you can launch with it, but you don’t have to.  So we take this set of user stories that you then agree upon as part of the signing off on the project and we essentially tackle them one by one and we go through working through get lab and different branches of code to create these new features in a staging environment, getting each of them in front of you, the client, as soon as we possibly can. So we get the feature built, we say hey, this feature has been built, this is what it looks like.  We might create a little video, maybe we hop on a call with you and say this is how this user login flow is looking.  

Q:  So under that, kind of the branch off in development as we’re building, the next step is functional prototyping, based off the user stories, right?  Getting the features and functions in front of the client to sign off, to confirm, to validate that’s actually what they were intending and what they needed?  

A:  Yeah, and sometimes that functional prototype does include the actually UI implementation.  So if Design is right there with us, rather than our frontend teams trying to build something really basic from a UI standpoint, just to nail down functionality, they can actually start implementing some of the base designs that we’ve all been working on, which only speeds that process up.  

Q:  So, after, let’s say we’ve functionally prototyped or delivered all of the user stories in development, and the client has signed off on them, where does the process go from there?  

A:  Now you’re ready to launch.  So you have a piece of software, it has all been written, we’ve got a whole bunch of tests that are behind it, we try to strive for 85% test coverage, usually we get a little bit higher.  But that gives us a little bit more confidence and reliability in the code that we wrote. It’s just an automated test that kind of again gives some confidence back to us as we go and add in new features.  So, now you’re ready for launch, and it’s figuring out what third party services are we leveraging, so let’s make sure those are all configured and set up. We like using Heroku as a platform and what Heroku is, it’s a platform as a service.  And so rather than us managing servers and infrastructure, Heroku takes care of all of that for us, and they run on top of Amazon AWS so we get a lot of benefits of Cloud without ever having to manually touch the Cloud. We are experts in building software and dealing with databases, Postgres, Redis, working with Rails, working with Node, but we are not experts and we don’t want to be experts in managing servers.  It’s not worth our time, and quite frankly it’s not worth our client’s time, until they’ve reached a certain scale, at which they have probably outgrown us anyway. At that point you’re probably going to have your own internal team because we’ve gotten to that point of so much success that you’ve just expanded. And so we get all that stuff configured, we move you over, it’s a rather seamless process, it usually takes less than a day, and then you’re up and live.  There are some circumstances to where people want to go into a beta phase first, to where they want to launch, but they don’t want it to be a hard launch. They want to get it in front of people, get some test cases in there, see if there is anything that maybe we need to tweak. Ideally we do this along the way, as we’re building out the project, and we say, hey, your login is ready, go and create a login, that’s why we usually start with logins, and then as we go along we can say, okay, go log in today and tell us what you think.  Go log in tomorrow or next week and tell us what you think. Have your friends go in there, log in, and tell us what they think. Because if we wait until the very end and you show all your friends, they go, well where’s this, where’s that? Then you’re kind of in this weird spot. Everybody is. So there is the potential to do that beta phase, as well, but typically we go right into launch, because we’ve done a lot of that beta user testing right there in the development process.