How to build your app as a non-technical founder: Part II

· 4 min read
How to build your app as a non-technical founder: Part II

Yesterday I wrote about the preparation steps you need to take before you start looking for developers and building your app. Interviewing customers, creating user stories and wireframes are essential for any product. Going through these steps allow your idea to evolve from a vague, abstract concept to a thought-through product with a defined look and functionality.

Hire a UI/UX designer

Once you’ve created your wireframes, you need to evaluate your goals to understand if you would need to hire a designer. Wireframes are good enough for developers to start working, but unfortunately, people who code are terrible at visual design. If you are building a tool where the function is more important than the form, or you don’t have the budget for the designer you can still make a viable product. Frameworks like Twitter Bootstrap and Google Material Design allow you to create apps with a clean, consistent and robust UI. These frameworks are customizable, and you can find a lot of themes for them online.

If you decide to create custom UI design, then wireframes you created in the previous step will make the designer you hire happy. They are the requirements designers need, a visual representation of your vision and your idea of user experience. Good graphics designer will be able to take your wireframes and convert them to a professionally-looking high-fidelity design ready for development.

Write down the spec

The product spec combines description of your goals, your vision and business context with user stories, wireframes or designs that you’ve created. With a clear, understandable spec you won’t have to explain everything you want to do again and again. The spec is a perfect way of providing information to potential hires so that they could estimate the amount of time needed to complete everything.

I would highly recommend splitting the spec into at least two parts — features that are an absolute must that have top priority and second-phase features. Estimates are always wrong, and the chances are that the project will take at least twice as much as was estimated. By defining priorities, you will make sure that critical parts are implemented no matter what. You need to be realistic and cut down everything you can from the initial version. For example, if you have a login/signup form, you might want to have email/password authentication build in the initial release and add auth via facebook and google later.

You can use something simple as PowerPoint or Keynote to create the spec. Start with a product overview and create slides for the screens you have (wireframes or high-fidelity design). Write user stories along the screens and add a list of additional requirements as a bullet list if there's something that hasn’t been captured by user stories or designs (those are usually non-functional requirements).

Your spec should include the desired platform, programming language and open-source packages you want to use. If you have trouble choosing them, you can hire a consultant to guide you through options and write this part of the spec for you.

Hire developers

With the spec ready you can start looking for the people who will build the product for you. How many developers will you need? It depends on the complexity of your application, your budget, previous experience of managing software development projects and of courses the amount of time you have.

I would recommend starting from hiring one full-stack developer in the beginning. Full-stack means that the developer will be able to work both on the server-side of the app (back-end) and the client-facing side (front-end). Hiring just one developer will help you learn the basics of managing the process without spending all your budget on the inefficient team. Working with one person is much easier than with a team of three.

To find developers, you can use one of the freelance marketplaces out there, like Upwork, Toptal or Guru. Attach your product spec to the job posting to weed out candidates that don’t have relevant experience. Don’t worry about someone stealing your idea — execution is much more important than the idea and chances that someone will use your spec are extremely low.

You will need to vet candidates that will apply to your job posting. Again, I suggest hiring a consultant with technical expertise to assist you with the interviews. Typically you would have a consultant to conduct a technical interview first to filter out people that don’t have skills that you need (you want to work only with the middle or senior level developers if the team is small). Then you would interview candidates personally to make sure you will enjoy working together and that you understand each other well.

During the interview you need to ask a few crucial things:

  • Developer’s background, where he is coming from
  • Have he read the spec? Does he have questions or insights about it?
  • What is his time estimate? What will take most of the time to implement?
  • Does his experience overlaps with your requirements?
  • What’s his preferred way of communication? Is he available for daily standups?
  • Is he ok with a trial period of one month?

I highly recommend agreeing on a trial period so that both you and developer could confirm that you want to work together long-term. Otherwise, you might find yourself in an awkward situation when things didn’t work out, but you don’t want to spoil your relationship with the developer because he already did something useful and you might need his help.

Daily standups are essential at the beginning of the project. They will allow you and the developer to understand each other better and quickly spot problems in the spec or designs and move rapidly.


It will take a while before you find the right developer. Take your time and make sure that the person that you are hiring is someone you want to work with because it will be likely that you’ll be working together for years. By preparing the spec, you’ve shown yourself and as a professional and you should expect that from your developers.

Next time I’m going to shed some light on managing the process, bugs, testing and getting customer feedback.