Preparing for a startup application development project

How we work with bootstrapped startups and fixed budgets

Introduction

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.

Fixed price web application development for startups

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.

Avoiding scope creep

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.

Project Management

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.

Be Explicit

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.

Bugs

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.

Reporting Bugs

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:

  • device and operating system
  • browser, and version of this browser
  • describe the steps you went through before getting to the problem (replication steps)
  • tell us which screen the issue is on and provide URLS (if a web app)
  • list the problem and what the expected ‘correct’ outcome is
  • if you can provide a screen grab please do. There’s nothing better than seeing the issue to know exactly what we’re dealing with.
Step by step project process

To further avoid surprises, scope creep and/or misunderstandings we follow these steps in developing your application:

  1. First contact - We send a cost estimate by email. We do this as there are usually many different ways to solve a problem. Plus you may prefer to save money and develop an MVP rather than the full product. Our first estimate is sent within an email to determine the best strategy for you.
  2. Meeting - We’ll usually have a couple of meetings, or phone calls, with you thereafter to ask questions we might have and so you get to know us. Developing a startup is hard work and so there needs to be a good personal fit too. You’ll find us easy going yet professional.
  3. Contract - Once we’ve confirmed a budget and requirements we’ll write up a contract that includes a scope of works. As mentioned already, this is a very important document. It will require some reading on your part. At this point we’ll also need a deposit to be paid to kickstart the project.
  4. Wireframes - following contract approval we’ll create and present wireframes to you. Wireframes are the next most important element after the contract (when working on a fixed-price project). Wireframes are essentially line drawings that show the desired user experience, user flows and page requirements. They can be changed and updated much quicker than designs or code can be changed so it is imperative that the wireframes are correct. They, along with the contract, become the brief for the design and development phases of the project. If you need to make changes, do them at the wireframe phase. Making changes later will lead to delays and additional costs. We’re happy to make multiple changes to wireframes, before starting design, to ensure you are happy.
  5. Design & frontend development - we’ll design the website in Photoshop, or sometimes we’ll design it in the browser during front-end development. If designed in Photoshop you’ll be presented with ‘flat’ images of the design for approval. These will be based on the approved wireframe. Thereafter, we’ll present front-end to you so that you can view it in the browser.
  6. Server, Database and Dev Environment - While design & front-end is happening we’ll be setting up the server infrastructure and setting up the development environment. We’ll then proceed with back-end development.
  7. Back-end development - depending on the complexities of your startup application this is usually where the majority of time will be spent. It is also often a time when you won’t be highly involved in the project. It isn’t a time to sit back and relax. During this phase you should be preparing for launch. You should be deciding on a launch strategy, lining up partnerships, introducing yourself to investors, preparing pitch decks, writing content etc. If you need assistance with this Launch Lab can help. Please just ask.
  8. Testing and User Acceptance Testing: once we’ve completed the work, and our internal testing, UAT will commence. You will be able to test the application on a staging server. This is an extremely important part of the project and the way we price our projects means that we expect your involvement. If you do not want to be part of UAT please let us know prior to the commencement of the project. We strongly advise that you allow a substantial amount of time for UAT and that you do get involved. After all, as an early stage startup founder you are the product manager.
  9. We’re live: Once the staging site is approved we move to the production server. That means you are live!
Nothing is obvious

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

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.

Design

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.

Development

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.

User Acceptance Testing

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.

What happens if I need to make changes

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.

What can I do while you are developing the product

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:

  • Strategy: What are you going to do the day your startup goes live? How are you going to acquire your first users?
  • Distribution: think about ways you can get your product in front of your target market in the cheapest possible way. Sometimes this comes in the form of partnerships. Start the conversations now. Get partners involved.
  • Marketing & advertising: what channels are going to work for you and is there a way to start testing them during development (note: LaunchLab can assist you)
  • PR: You’ll want to tell the world when you go live. If you can’t afford to hire a PR agency then start reading up on how to draft the perfect press release. Plus, you can use this time to start relationships with journalists that you’d like to write about your product
  • Wish List: During development you’ll no doubt think of other ideas and other features for your product. Keep a wishlist and start prioritising. We can jump onto these as soon as we’re finished with version 1.
  • Investment: If your strategy is to acquire funding from investors then start the conversation with them now. Start refining your pitch deck and start attending pitch sessions. The more pitches you see and the more you pitch the better you’ll get.
Staging vs Production

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.

Code Repository

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.

Amazon Web Servers

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.

Stripe

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.

Common Misconceptions

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.

Methodologies

In terms of project management we use Agile Kanban. In terms of development we follow a test driven development approach.

Final Word: Fixed Price vs Agile Pricing

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.