wait just start

How to Build an App




The goal of this post is to document an approach to build an app. If you have an idea, this post outlines a path to build it.

It contains the knowledge I've gained in the last 5 years as a Product Manager in both startup and corporate environments.

It's a step-by-step guide I wish I had.

This post is intended for all levels of experience and professional backgrounds. No esoteric knowledge required.

Reading this post will be like plugging into the Matrix and uploading the "Build an App" program into your brain.

Topics include:

  • Thinking about your idea
  • Mindset
  • Mockups
  • User Stories
  • Project managing a development team

Throughout I'll provide examples from Bechant, an app two friends and I recently launched. Bechant is a tool that will email you a random selection of your Kindle Highlights.

If you have an idea or a desire to build a product, this post documents one way to do it.

Plug in.




Section A: Philosophical

Idea Part 1. (Visualize)
Idea Part 2. (A job to do)
Idea Part 3. (Excel test)
Idea Part 4. (Why build it?)

Mindset Part 1. (Be a minimalist)
Mindset Part 2. (Set your team up for success)

Section B: Practical

Mockups Part 1. (Introduction)
Mockups Part 2. (The good enough MVP approach)
Mockups Part 3. (How to: drawing approach)
Mockups Part 4. (How to: software approach)

Development Part 1. (Getting started)
Development Part 2. (Tech stack 101)
Development Part 3. (Tech stack 201)
Development Part 4. (The User Story)
Development Part 5. (Essential features for launch)
Development Part 6. (Project management)
Development Part 7. (Testing aka QA aka UAT)
Development Part 8. (Release to production)


Contact Me


Section A: Philosophical


Idea Part 1. (Visualize) top

Disclaimer: no amount of visualization and research can guarantee the success of your idea. You'll only know if you built something users want after you release your app.

BUT you must invest time to evaluate and refine your idea before you build it.

More time than you think.

Let me set the stage.

When you identify a problem and come up with an interesting solution, you lose objectivity. Your internal dialogue is overcome by observations that mostly reaffirm your idea. You think: it's a great idea, people need this to exist. Why wouldn't they use it?

You visualize a merry world where your product exists and users are using it. Yet you do not visualize the step between releasing your product and getting users.

What happens at that step? Where did all those users come from?

Say you just launched your app Turtbnb. It's Airbnb for turtles. Are users going to open the App store, know to search for "Turtbnb", download the app, sign up for an account, and become active users?

Your answer may be a resounding "YES"! Yet this optimism is not driven by logic or research, but by your fresh excitement from the novelty of the idea.

Move past your excitement and get to a state where you can evaluate your idea objectively.

Consider two mindsets. The idea phase and the experience phase.

The idea phase mindset lacks objectivity. It's the "this idea can't fail" phase. You don't understand or acknowledge the ways the idea can fail.

Here is something someone in the idea phase may say:

Users will search "Airbnb for turtles" in the App store and will download my app. Word of mouth is how I'll get thousands of users.

The experience phase mindset typically surfaces after you launch your product and have tried to acquire users. It's the "the idea didn't work because of..." phase. You've learned the reasons users didn't adopt your product and they make sense to you because you've gone through the experience of failing.

Here is something someone in the experience phase may say:

My target users don't search "Airbnb for turtles" or "Turtbnb" in the App store. They search and download Airbnb instead.

Why must you launch your app before some of the reasons it failed make sense? Do you need to go through 6 months of development to reach the experience phase? To learn those lessons?

Try to visualize today what you think you will learn six months from now. Where will you succeed? Where will you fail?

How does this visualization reshape your idea?


Idea Part 2. (A job to do) top

Your idea should solve a problem. A real problem.

Read this post for additional detail.

The takeaway:

When we buy a product, we essentially “hire” it to help us do a job. If it does the job well, the next time we’re confronted with the same job, we tend to hire that product again. And if it does a crummy job, we “fire” it and look for an alternative.

What job will your app be hired to do?


Idea Part 3. (Excel test) top

Does your idea pass the "Excel" test?

Could I use an already existing product to solve the problem your product solves?

Say your idea is a tool that keeps track of my digital subscriptions (HBO NOW, Amazon Prime, etc.) and when they renew.

Am I more likely to A: take time out of my day to Google search for your tool, find it on the first results page, click the link, sign up for an account, and upload my data? B: create a spreadsheet. Or C: do nothing because I get email alerts when my subscriptions renew.

What is my level of motivation and pain to look for and discover your tool versus repurposing a product I already have.


Idea Part 4. (Why build it?) top

You should build this product because you need it.

Your idea solves a problem you have.

If a sufficient product already existed, you would use it instead of building your own.

But it does not exist so you'll build it.

You're creating something you will use.

Read Paul Graham's "How to get Startup Ideas" essay for more on this.


Mindset Part 1. (Be a minimalist) top

Be a minimalist.

You'll need to make a lot of decisions while building your app. Having a minimalist mindset will keep the process flowing.

You have a product idea but no guarantee that users need it. Worst-case scenario is you invest time and money to build a feature rich product, launch it, and get zero users.

To avoid this pitfall strive to launch your product to real users as quickly as possible.

To launch as quickly as possible, be a minimalist. Determine the absolute minimum you need to create so that you can test your idea with users.

Eric Reis in his book "Lean Startup" popularized the acronym "MVP". Minimum viable product. The MVP of your idea is the simplest iteration of your product that users can use.

For example Product Hunt started as an email newsletter. The founder manually added subscribers to the email list and sent out each newsletter. The email newsletter was the MVP of the idea. It allowed the founder to gather a user base and validate the idea before investing time and money to build the product you see today.

What's the MVP of your idea?

What is the minimum that you need in order to test your idea with users? The first version of your app doesn't need to be perfect. Does the first version even need to be an app?

Strive to build as little as needed. Be a minimalist.

Reid Hoffman founder of LinkedIn offers this MVP advice:

If you are not embarrassed by the first version of your product, you’ve launched too late.


Mindset Part 2. (Set your team up for success) top

It's your responsibility to ensure your team succeeds. How?

Set your team up for success.

Visualize yourself in the situation of the person doing a task. For example a developer writing code for a feature in the app.

Do they have all the information they need? Are the requirements clear? What challenges may they face?

By putting yourself in "their shoes" you'll be better equipped to anticipate roadblocks.

Avoid ambiguity. Ambiguity leads to miscommunication, frustration and delays.

To avoid ambiguity be explicit in your communication.

Don't assume your teammate knows what you know. Don't assume the task being worked on will be completed exactly to your expectations. If necessary, put in the extra effort to over-communicate to avoid ambiguity.

When challenges arise, focus on implementing processes to avoid repeating such problems. Focus on the remedy instead of a person to blame.

As an aside, if miscommunication does occur the remedy is two questions:

  1. What was the intended result?
  2. What actually happened?

Do whatever is needed to ensure your team builds the right product.

No task is beneath you. If no one is taking meeting notes, take notes. Follow up on things that need follow ups so that your team can succeed.

Do whatever is needed to ensure your team's success.

You'll know what will be needed. Your actions on those needs will correlate to your team's success.

And embrace that it's always your fault.

If you're part of a team or a process and something went wrong, of course it's also your fault. You could have looked harder. You could have raised your doubts. You could have double checked.

Set your team up for success.


Section B: Practical


Mockups Part 1. (Introduction) top

Mockups (aka sketches, prototypes, wireframes, storyboards) are pictures of the screens in your app.

Here is a mockup from Bechant:


You (as the product lead) should create the initial mockups. Doing so will help you think through the idea and how it will work. It will help answer fundamental questions such as what are the core features? How will users navigate from one screen to another? What will they see when they first log in?

Mockups are the first step to shift your idea to something tangible. They should be created before development begins.

Mockups can be used in various ways. To gather feedback from users so that you can affirm that you're building something they want. To be shared with a designer who'll use them as reference to create professional mockups. Or shared with a developer so that they know what needs to be built.

You don't have to be a designer to create mockups. Visualize yourself using the app and draw out what you see. It's your idea, draw it based on how you want it to function.

Jeff Bezos (Founder/CEO of Amazon) in his letter to shareholders offered this wisdom:

A remarkable customer experience starts with heart, intuition, curiosity, play, guts, taste.







Keep these nouns top-of-mind when creating your mockups.


Mockups Part 2. (The good enough MVP approach) top

The MVP approach with mockups is to focus on the app's core functionality. What will the login page look like? Where will the user go after they log in? What buttons will they see?

The goal is to create a basic outline of your app. Each image depicts a screen in the app, such as "login screen", "user profile screen", "logout screen", etc.

Focus on critical features that must be in the first version of your app. Don't overthink design nuances. For example think more about the buttons you will need instead of what color they will be.

Take a "good enough" approach and move on.

If a section of your app contains a button, but you don't know what label the button will have, just label it "Button" or "This button goes to user profile".


If the button is going to be blue, don't lose time determining what shade of blue looks best. Set a generic blue and refine it later.


If the mockup conveys the purpose of the screen, it's good enough.

Here is a sketch of the primary page users see after logging in to Bechant:


Here is mockup version 2 of this page:


And this is the live page on Bechant:


The live product may not look exactly like your mockups. This is OK.

In the above examples the last image includes the key elements of the previous mockups. Figuring out the key elements is your objective when creating MVP mockups.


Mockups Part 3. (How to: drawing approach) top

Here is a step-by-step guide to create your mockups. Adjust to your needs.

Start with a notebook and a pencil.

Draw a rectangle in the shape of an iPhone. It represents a blank mobile screen.

Determine the function of this screen. For example it's the landing screen (the first screen users see when they open your app).

Draw the elements (placeholder text, buttons, input fields) that will appear on this screen. Keep it simple. If an area is going to have a tagline or marketing text, you don't need the exact text at this moment. Draw a box and label it "marketing text".


Your goal is to determine the elements each screen needs. Specifics (such as button labels and marketing text) can be determined later.

Draw another rectangle and determine the function of this screen. For example it's the first screen a user will see after they log in. Draw the elements on this screen.

Add additional screens until you have a complete set.

Take a photo of each screen and upload them to Invision. Invision is an app prototyping tool. Use it to "connect" your screens and make your mockups interactive. (Invision calls this adding "hot spots").

Here is an example I created.

Visit Invision's documentation for detailed examples on how to use the tool.

Without writing any code you now have an interactive prototype that you can share with prospective users or your development team.


Mockups Part 4. (How to: software approach) top

In this approach use software to create your mockups instead of hand drawing them.

If you're on a PC I recommend Balsamiq.

If you're on a Mac I recommend Sketch or Balsamiq.

As described in part 3, start with an empty rectangle and add elements based on the function of the screen.

Here are examples of screens for Bechant I created using Balsamiq.




I added each image to Invision and created this interactive prototype.

Once you have a prototype you are happy with, you are ready for the development stage.

If you'd like additional detail on creating mockups check out my post on building a prototype.


Development Part 1. (Getting started) top

Development is writing the code that will make your application work. It includes "QA" (quality assurance) testing and launching your application to a live (production) environment.

Clear communication and a detailed development plan will save time and ensure the development team builds the product you are envisioning.

If you prefer to learn to code and build the first version on your own, dig into this post for a sense of what that entails.

I recommend exposing yourself to web programming basics so that development isn't a black box. By basics I suggest learning HTML, CSS and JavaScript.

Codecademy courses are excellent for beginners. Start with these two:

If you prefer books start with these:

Having familiarity with web technologies will elevate your confidence and increase your empathy when working with the development team.


Development Part 2. (Tech stack 101) top

Your technology ("tech") stack are the components that comprise your app. Like the engine, tires, and body frame components of a car, each serves a specific function.

For a web application start with a domain name and a host.

The domain name is the link to your site. For example Bechant.com or ForwardShapes.com. You will need to find and register a domain using a solution such as Google Domains.

You will also need a host. A host is a server (aka computer) that "hosts" the code for your app. When someone navigates to your domain (such as Bechant.com), the host sends back the app code to your web browser. Your web browser interprets the code and displays the contents of the app.

There are hundreds of companies that provide hosting services. Things to consider when selecting one:

  • Supported technologies
    • For example, if your app is built using Microsoft's .NET technology you need to find a host whose server supports this technology (different hosts support different technologies such .NET, Python, NodeJS, etc.).
  • Reliability
    • Also known as "uptime" - you don't want to be worried about your app being unavailable because the host is having server problems. This wont be an issue if you pick a popular host.
  • Price
    • A reliable host can cost $10-$15 a month.
  • Support
  • Security

Here are some popular and well known hosts: Heroku, Bluehost, Microsoft Azure, Amazon Web Services (AWS).


Development Part 3. (Tech stack 201) top

A basic web application has three components: a domain, a host that stores the app code, and a database for storing user data.

Your tech stack will be determined by your budget, time frame and application needs. Furthermore, you must determine what your team will build in-house versus using a 3rd party solution. This decision depends on several factors including time, cost, and how much flexibility/customization the 3rd party solution offers.

Let's go through the tech stack for Bechant.

Domain registrar: Google Domains.

Hosting and Database: Firebase.

Firebase is a mobile and web application development tool. All the code that creates what you see on Bechant is hosted (stored) on Firebase.

Firebase includes our database, which stores Kindle Highlight files users upload.

Before beginning development we decided that we would not spend time building our own database solution. Our core product feature is the Kindle highlights email. The database is an accessory that just needs "to work" without much customization. Therefore we decided to use a packaged database solution instead of building our own.

Email Service: Mailgun.

Mailgun is a tool that allows you to send customized emails in bulk. All Bechant emails that contain Kindle Highlights are sent by Mailgun.

Instead of building our own email sending tool from scratch, we were compelled by the reliability, pricing and ease of use of Mailgun. After creating an account and adding a few lines of code, we were able to start sending emails to users.

Additional hosting: Heroku.

Bechant sends users three emails per week with their Kindle highlights.

For this to happen a Node.js script on Heroku is scheduled to run Monday, Wednesday and Friday at 6:30 AM EST. This script communicates with Firebase and retrieves user emails and Kindle Highlights. It then creates an email for each user and sends the data to Mailgun, which then sends one email to each user.

Server logging: Papertrail.

This service provides activity logs of our servers. This is primarily for the development team so that they can troubleshoot any issues (such as users not receiving emails) that may arise.

Web traffic data: Google Analytics.

Used to collect anonymous data regarding how many users are visiting Bechant and the pages they are viewing (including time spent on specific pages).

Visual look of Bechant: Material-UI.

This is a user interface (UI) framework that provides pre-made components for creating user interfaces. For example the buttons you see on Bechant are created by Material-UI. We just customized the color.

Material-UI makes our app "responsive". This means the app will automatically resize depending on the size of the device. For example if you're viewing Bechant on an iPhone or iPad, all visual components will "respond" and shift to accommodate the different screen sizes. This allows us to have one codebase that supports any device and screen size.


Development Part 4. (The User Story) top

In a perfect world you send the development team a link to your mockups and they produce a bug free product that works exactly as you envisioned.

Reality is much more complicated.

As a developer writes code they may come across "ambiguous product situations". They are not sure how the product should behave.

For example say your application allows the user to upload a profile picture. What if the user tries to upload an Excel Spreadsheet file? What if the file is 1 kilobyte or 100 megabytes? How should the application behave? Should it display an error message? What does the error message say? What buttons are in the error message? Should you even have buttons? Are we sure we need an error message?

Ambiguous product situations are disruptive. Think of a developer as being on a Maker's Schedule.

There's another way of using time that's common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.

When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.

Two things disrupt a developer: meetings and ambiguous product situations. Instead of focusing on writing code the developer is thinking about what they should be building.

Strive to optimize a developer's time so that they can focus on building. Minimize ambiguous product situations.

The User Story is a tool to overcome ambiguous product situations.

A User Story defines how a feature works. It explains WHAT should be built so that a developer can focus on the HOW.

The how is referred to as "implementation details". It's specific to the development tasks and code strategy. Exclude implementation details from your User Story.

A User Story should focus on a specific feature. Split a large feature into multiple User Stories. This makes the work manageable for the developer and the QA tester.

Here is a User Story template:

Story Title: My Story

Description: As a user I'd like to be able to do something.







Here is a User Story I wrote for Bechant:

Story Title: Highlights Collection page displays uploaded files

As a user I'd like to see a list of all files I have uploaded.


1. User is logged in and navigates to bechant.com/username

2. User has uploaded at least 1 file


1. User presented with "Highlights Collection" page (see mockup)

2. Table contains rows containing names of uploaded XML file(s)

2a. Exclude .XML extension from file name

2b. If long file name, extend name to second line (do not cut off file name or add ellipsis)

2c. Each row is numbered (first row number = 01)

3. Table should display all files that user has uploaded

The Story Title encapsulates what the story is about.

The Description is a sentence or two that describe the purpose of the story. It can be written from the perspective of the user.

Start a Description with one of the following:

  • As a user I'd like to...
  • The purpose of this story is to...

The Preconditions set the scene for your story.

What situation is the user in? Did they just click a button that brought them to a specific page? Did they upload a non ".JPEG" file that is 100 megabytes for their avatar?

Set the scene.

The Postconditions outline how the feature should behave.

They are bullet points and don't have to be complete sentences.

They are testable. They will be a checklist of everything to test when you are reviewing the feature. Once all Postconditions pass testing the feature is ready for release to production.

They are broad, yet specific. For example this Postcondition gives the developer a specific goal to reach:

Results appear in under 1 second

Postconditions provide clarity on how a feature should work. What is clarity? It's enough detail so that if you were the developer, you would know what needs to be built.

Be explicit in your Postconditions. Eliminate ambiguity. The more thorough your Postconditions, the more likely the feature will be built to your vision. Overly broad Postconditions leave room for interpretation and more points of failure.

If you have over 10 Postconditions (not counting sub-conditions), consider splitting them into multiple User Stories.

Here is another User Story from Bechant:

Story Title: Delete a file

As a user I'd like to be able to delete any file that I have uploaded to Bechant.

1. User opens Highlights Collection
2. User clicks on checkbox next to a file

1. Display action menu at the top of table (use Material-UI `app bar`)
1a. Color of App Bar should be: `rgb(97, 100, 137)`
2. App bar has `X` icon to dismiss the selection (clicking the X closes the app bar and un-selects the checked item in the table) - use Material UI close asset (https://material.io/icons/#ic_close)
3. Add link to `DELETE` (see Design-Inspiration)
4. Tapping on `DELETE` generates Material-UI `Dialog` element
4a. Use `Simple Dialog`
4b. Dialog Header text: `Delete file(s)`
4c. Dialog Body text: `This will permanently delete your file(s).`
4d. Dialog Buttons: [Cancel] & [Delete]
5. If user taps [Delete] permanently delete the files from Google Storage
6. Highlights Collection table should automatically refresh and no longer list the deleted file

Here is this story on our development board:


If you're new to User Stories start by writing several drafts for one feature.

Share these drafts with your development team. Collect feedback and revise the User Story until it's deemed optimal by the team. Your goal is to find the writing style that results in a clear and useful User Story for your team. This exercise will also help you discover how much detail the team needs in the User Stories.

Remember the reason for the User Story: to avoid ambiguous product situations.

If your User Story satisfies this condition, it's good to go!


Development Part 5. (Essential features for launch) top

Recall the Reid Hoffman quote mentioned in Mindset Part 1:

If you are not embarrassed by the first version of your product, you’ve launched too late.

Put together a list of "must have" features for launch. This list can include features such as:

  • User login
  • Password reset
  • Share data with Twitter

Your list will be determined by what you deem essential for launching the MVP version of your product. You will likely need less features than you think.

Here is the list of User Stories I deemed essential for the first version of Bechant:

  1. User can create an account
  2. User can log in and log out
  3. User can reset password
  4. User can upload one or more highlight files as XML, CSV, or HTML
  5. Email users 3 digests containing Kindle Highlights per week
  6. Highlights Collection page displays users' uploaded files
  7. Highlights Collection empty state
  8. About, How To Guide, Contact, Privacy Policy, and Terms of Services pages
  9. Bechant.com is responsive and supports mobile devices
  10. Highlights Collection Footers to indicate email status

If I wanted to launch even faster, I could have cut the list to the following:

  1. User can create an account (I would manually create accounts for users and email them their username and password)
  2. User can log in and log out
  3. User can reset password (Users can email me and I will reset their passwords)
  4. User can upload one or more highlight file as a XML, CSV, or HTML
  5. Email users 3 digests containing Kindle Highlights per week
  6. Highlights Collection page displays users' uploaded files
  7. Highlights Collection empty state
  8. About, How To Guide, Contact, Privacy Policy and Terms of Services pages
  9. Bechant.com is responsive and supports mobile devices
  10. Highlights Collection Footers to indicate email status

When considering cutting features, adopt the mindset to "Do Things That Don't Scale".

Do something manually until it reaches a breaking point that a programmatic solution could fix.

For example manually resetting user passwords does not scale. I couldn't do it manually if Bechant had thousands of users. However I currently don't have the "problem" of having thousands of users that need to reset their passwords. So why build a feature that solves a problem that I currently don't have?

Solve the problem when it actually is a problem. Often the future problem you're concerned about solving now so "you're ready for it" won't manifest.

Throughout the development process continue to re-evaluate essential versus non-essential product features.

Re-evaluate your Postconditions and cut them as well.

This will simplify your product and allow you to launch quicker.


Development Part 6. (Project management) top

At this stage you should have a complete set of essential User Stories and mockups. After development completes these Use Stories, your product will be ready for launch.

There is a system for tracking and managing the development process. It provides full transparency to the team as to what work is pending, in progress, and complete.

The system is a development board like this:


This development board is created on Trello.

Each card is a User Story. Each card has a:

  • Title (Story Title)
  • Description (Story description, preconditions, postconditions)
  • Attachments (Mockups)
  • Comments (For discussions and updates around this User Story)


The "status" of each card is based on the list (column) it's in. Your development board should have these five lists:

  1. For Launch
  2. In Development
  3. Development Complete
  4. Closed
  5. Backlog

For Launch is the "to do" list. On day one of development this list will contain all cards that need to be completed so that the product can be launched. It's the "must have" User Stories list.

Once a developer begins working on a card, they should move it to the In Development list. If a developer is writing any code for a card, that card should be in the In Development list.

Once a developer finishes writing code for a card, they move the card to the Development Complete list. This means the card is ready for testing.

After testing there are one of two outcomes. If the card does not pass testing, changes to the code need to be made. Thus the card should be moved back to the In Development list.

If the card passes testing, it is ready to be released to production. This means development work on this card is complete and it can be moved to the Closed list.

During the development process new feature ideas will surface. This can include development optimizations to your Closed User Stories, or new ideas for features to add. These ideas should be added to the Backlog list.

The Backlog list is a collection of all future "to dos". Development does not begin work on any card in the Backlog until it's moved to the For Launch list. Cards in the Backlog do not need to be fully written User Stories with pre and postconditions and mockups. They can be placeholders containing ideas or tasks to be done in the future.

You should have a compelling reason for moving a card from the Backlog to the For Launch list.

For example during the development process of Bechant we were going to support only XML Kindle Highlight files. But new information surfaced during the development process. We realized we should also support HTML and CSV files. Thus support for these file types became a card (User Story) that was moved from the Backlog to the For Launch list.

Be disciplined about which cards you move from the Backlog to For Launch. Your goal is to launch as quickly as possible. Thus consider the risk of delaying launch versus the added value this additional feature will bring.

If the value outweighs the risk, move the card to the For Launch list.


Development Part 7. (Testing aka QA aka UAT) top

When a User Story reaches the Development Complete stage, it's ready for testing. This is referred to as Quality Assurance (QA) or User Acceptance Testing (UAT).

It's essentially testing the User Story and how it performs with the application. Once the story passes testing, it can be released to production (to real users).

There isn't a "right way" to perform testing. Here is one approach.

Say we are testing the story:

As a user I'd like to be able to delete any file that I have uploaded to Bechant.

Start by performing the Preconditions. Set the stage.

1. User opens Highlights Collection
2. User clicks on checkbox next to a file

Now test each Postcondition:

1. Display action menu at the top of table (use Material-UI `app bar`)
1a. Color of App Bar should be: `rgb(97, 100, 137)`
2. App bar has `X` icon to dismiss the selection (clicking the X closes the app bar and un-selects the checked item in the table) - use Material UI close asset (https://material.io/icons/#ic_close)
3. Add link to `DELETE` (see Design-Inspiration)
4. Tapping on `DELETE` generates Material-UI `Dialog` element
4a. Use `Simple Dialog`
4b. Dialog Header text: `Delete file(s)`
4c. Dialog Body text: `This will permanently delete your file(s).`
4d. Dialog Buttons: [Cancel] & [Delete]
5. If user taps [Delete] permanently delete the files from Google Storage
6. Highlights Collection table should automatically refresh and no longer list the deleted file

Each Postcondition should either Pass or Fail.

If a Postcondition fails, decide if it's a "showstopper" failure or if it's a "fix later" failure.

For example say Postcondition #6 failed. After deleting a file the user has to manually refresh the browser in order for the file to disappear from the page. You must decide if this failure warrants sending the story back to In Development or if it can be Backlogged and fixed at a later date.

You should do some exploratory testing.

Try to "break" the application with edge cases. For example what if I refresh my web browser the moment after clicking the Delete button? Am I able to simultaneously click both the Cancel and Delete buttons?

See what happens when you perform actions that don't align with how this feature should be used. There is a difference between how you expect a user to use a feature versus how they actually use it. These are "edge cases". Try to recreate certain edge cases and see how your application performs.


Development Part 8. (Release to production) top

Once you complete testing of a User Story and have deemed it a Pass, the card can be moved to the Closed list.

The User Story is ready to be released to production. This involves sending a copy of the code from the "development branch" to the "production branch".

The development branch is the sandbox/staging environment where new code is written for your application. It's only accessible to the internal team. Real users cannot access it.

Once a User Story passes testing, it's ready to be sent to the "production branch". This is the branch that has code that runs when real users access your application.

After a User Story is released to production, you should perform some light "sanity" testing in order to confirm that the feature is behaving as expected on the live app.

If all works as expected remember to congratulate your team on another successful release!


Launch top

Congratulations - you are among the few that not only had an idea, but built it.

You wanted this product to exist in the world and now it does.

For your first set of users I recommend friends and family. They will be much more forgiving to the unforeseen glitches that come with a first version. Plus their feedback may lead to valuable enhancements that will improve the experience for future users.

So how do you get users?

If only I or someone had the "right" answer...

It's a combination of timing, luck, market-product fit, and more luck.

You built a product for a certain type of person. A certain profile. Where do people that meet this profile hang out? What do they read? What are their habits? Your challenge is to figure all of that out and to place your product there.

Jason Calacanis summed it up in two words:

Be everywhere.

There is no right way to do it. There is just your way. This post is part of my marketing strategy for Bechant. My strategy is to have you discover Bechant through a post that may provide you with more value than the product I'm promoting.

As a favor please share this post or Bechant with someone who may dig it.

Remember you're building a product because you believe in it's value. You believe that it's needed.

Share it with the world.

Good luck!


Contact Me top

A big thank you for reading this post. I sincerely hope it was helpful!

Did reading this post help you build your product? Tell me about it!

Did I miss something that you wished was covered?

General feedback?

Send me a note at andrei@forwardshapes.com