How we work with bootstrapped startups and fixed budgets
Software development projects are unlike any other large project you will ever undertake. Couple that with the bigger picture of creating a technology startup and you’re in for an exciting, challenging and completely rewarding experience.
Most of the entrepreneurs (founders) we work with are first time entrepreneurs and this will be the first time they are part of an application development project. This can be daunting and we feel that information is power. Knowing what to expect will not only prepare you for the journey but will make for a smoother first foray into the world of technology startups.
This guide reveals how we work and what you can expect when working with Launch Lab. We hope that by being upfront and applying certain ‘rules’ we don’t come across as being too rigid. The items listed below are provided to make the process of developing a startup easier for you, the founder.
If you are bootstrapping your startup (funding development on your own) then you’re probably investing a large sum of your own money and you want to know how much to budget. With this in mind, we quote on a fixed price basis.
This approach is fraught with danger for us as software development projects are typically difficult to estimate (the majority of corporate development projects come in over budget and over time), but we feel that for startups it makes the most sense. However, working within a fixed price means applying rules to the process. These rules, or rather guidelines, are discussed below.
Alternatively, we're open to a more agile pricing approach if you feel that will work better for you.
Unless we’re developing a very straightforward application our project timelines are usually in excess of 3 months from project approval. In most cases we would have started conversations with the founder more than 4 weeks before the project begins. Over the course of the project we will have many conversations both verbal and written. With this amount of communication over an extended period it becomes nearly impossible to remember everything. We avoid ‘he said, she said’ discussions as they are costly and waste time. To avoid confusion we write a Contract before the project commences. The Contract lists all features and requirements of the project as we understand them at that point in time.
The cost estimate provided is directly tied to those features and requirements. The contract becomes our single source of truth. Any deviation from this means additional costs and time. Plus, contracts are accepted on the basis that if something isn’t in the contract it was never said. That makes things fair for you and us and ensures we always have a common understanding. You always know where you stand and if you have any questions or doubts then the answer is always the same as it is written in the contract.
The contract can be changed and updated but this usually means the project timeline and cost increasing.
To further ensure that things don’t go missing and are explicit we track projects with our clients using either Trello or Jira. We use Trello for communication between ourselves and our clients. Sometimes we’ll ask our clients to use Jira. We might not necessarily use these tools for our internal project management but we’ve specifically selected them for our clients to use as they are user friendly and have a low barrier to entry. They’re simple, yet powerful.
Usually if a request is made within these tools for something that is not within the scope (not in the contract) we will move the request to a ‘Change request or enhancement’ list. Changes and enhancements will usually be done after the requirements of the initial contract have been fulfilled. This is the best way to stay within the fixed price. However, we are flexible and can accommodate enhancements and changes during the project on the understanding that costs and timelines will probably increase.
We prefer that all communication be explicit. Mis-understandings can be costly. Ideally anything that is said, or written, is done in an explicit way. Short and succinct works for everyone. We won’t be offended if you describe something to us as if we’re 5 years old. It means we’ll understand exactly what you’re asking for. If we do the same, please don’t be offended. It’s critical things are done right and that comes from clear understanding.
We all hate bugs, but unfortunately they are part of the process. We do as much as we can to eliminate bugs but the reality is that they will appear. You’ll probably come across bugs during the UAT (User Acceptance Testing) process and you’ll need to report these to us (within the project management tools mentioned above). Testing always takes longer than you think it will. Plus, once we’ve fixed a bug you’ll probably want to test again before approving it. Also keep in mind that the larger your project the more bugs there are likely be and therefore the more time you’ll spend testing.
This all ties back to our competitive fixed prices. If you prefer to be left out of testing completely please let us know. It will mean additional fees so that we can cover our time for additional testing. However, as a startup founder in the early stages, you are essentially a product manager too. Testing makes you an expert on the product and means you’ll know exactly what your users will see. Plus, the more you test the more you’ll find things you’d like to improve in future versions of your product.
Assigning UAT responsibilities to you does NOT mean we don’t run internal tests prior to releasing to you. We write testing scripts to automate unit tests during development and we test everything prior to releasing to you.
The more we understand the issue the quicker we can fix it. When reporting bugs be explicit. We need to understand the steps to replicate and we need to know what environment you were testing in. For example, reporting: “the website is slow to load” could make us look in many different places. However, if you said: “As a user, I’m on the homepage of the website. I click ‘Signin’ and complete the signin form. After clicking the signin button it takes more than 8 seconds for the dashboard to load. I am using a laptop on the train and connecting to the internet via 3G”. Now we know what we’re dealing with and can test accordingly.
Letting us know the following things when reporting a bug makes troubleshooting quicker:
To further avoid surprises, scope creep and/or misunderstandings we follow these steps in developing your application:
We’ve mentioned the importance of the contract and the scope of works within it. The price quoted in the contract is tied directly to the features and requirements listed therein. When you get to UAT you might come across minor enhancements that you’d like to make, or you may think “why haven’t they added this”. If the exclusion is not listed in the contract, regardless of how obvious it may be, then it isn’t included and would go down as an enhancement or a change request.
This applies to UX items (user experience) too. During testing you may feel that the user experience could be improved. The most successful startups in the world are constantly improving their UX and they don’t have the time, resource and budget constraints that you have. Any UX changes are change requests. The best advice we can give is to think through all UX issues during wireframing. It is quicker to change a wireframe than the actual application.
Wireframes are essentially line drawings showing the requirements of the key screens in your application. They are used to determine the user experience, page content and page requirements.
Our quotes include up to 3 changes to wireframes, unless stated. The most efficient method of using those changes is to provide 1 document with feedback on all wireframes each time changes are requested. Wireframes are extremely important. Once approved they direct the web designer and the design process. Major changes during the design phase are much more expensive than making those changes in the wire framing phase.
We don’t expect major changes during design because we only start on design after approval of the wireframes and after approval of a creative brief. After the initial presentation of design (we will usually present a homepage and 1 other page for a web application in the first design presentation. The approval of these screens dictates the overall design direction for all other pages), our contract allows for up to 2 rounds of changes to the screens presented in the first presentation.
Based on our development process, by the time we’re into full development of the product there shouldn’t be changes and thus there are no changes included in the contract at this stage of the process. This is based on a fixed fee project.
We allow for a UAT period of 7 days. We’ll fix any bugs reported during this time. Bugs reported after the 7 day UAT period will be fixed but fall outside of this scope of works and will usually incur a fee.
If you have to make changes then we can accommodate it. However, keep in mind that this will incur costs and will add to the timeline. We strongly suggest that once the contract is signed, if you want to make changes rather keep a ‘wishlist’. Every startup wants to, and has to, continually improve their product. But, you also want to get to market as quickly as possible and within budget. The quicker you get to market the quicker you’ll find out what your users really want. Let them dictate the changes and the priority thereof.
Lots! In the early stages of the project there will be a lot of reading to do (the contract). You’ll also be very involved in the approval process of wireframes. Remember that as the founder you are the product manager. We’ll guide you but you need to be involved at this stage. As we get further into the project you’ll be less involved until we get to UAT. This is usually a frustrating time for founders as they don’t yet have a product and they aren't developers so they feel like there isn’t anything they can do. There is. Here are some ideas:
During development we test on a staging site. This is where you will conduct UAT. When we are ready to go live we’ll setup a production server. Production is where your live website will be. Once we’re live, staging is kept so that changes and new features can be tested on staging prior to releasing them on production for the world to see.
While writing the code for your startup we commit code to a Git repository regularly throughout the day. We’ll give you access to the repository so that you always have access to your startups code (the code is yours once the final invoice has been paid). We use a product called BitBucket for this.
This is where we host your application. Depending on the complexities of your product we may use a range of AWS resources including EC2, RDS, SES and more. You don’t need to know what these are, just know that your application is hosted on the world’s leading cloud-hosting infrastructure.
If your users need to make payment on your website we use stripe.com as the payment gateway. We’ll ask you to create a Stripe account meaning you hold the ‘keys’ to the most important parts of your startup. If your startup is a 2-sided marketplace we’ll probably use something called Stripe Connect to facilitate payment from, and to, both sides of the marketplace while allowing you to take a fee as the middleman. Stripe is a billion dollar business and is one of the leaders in their field. They are highly trusted and very developer friendly.
A common misconception for first time startup founders who have not been involved in a software development project before is that once the application is live then all development work ends. Depending on your startup idea and the complexities of what is developed, there is a very good chance that when we go live you may think the site is finished but you’ll still need a developer. If we have created a straightforward MVP then we probably are finished and you won’t need our help until you decide to add more features. If your product is more complex there is a high likelihood that you will need our help each month. This might only be a few hours each month but experience tells us that you will need to budget for at least a few hours each month. The time gets spent on things like server maintenance, bugs, enhancements, new features, or to handle scaling if your product is proving to be successful.
In terms of project management we use Agile Kanban. In terms of development we follow a test driven development approach.
We hope the ‘rules’ above don't sound too rigid. We’ve created these guidelines to help you following years of experience developing startups. The reality is that as a bootstrapped startup your main constraints are time and money. Our process and fixed price offer caters to, and addresses, these constraints.