And 7 pitfalls to avoid if you want to build a great product

Technology can be transformational.

Smart, beautiful, well-built applications have given us power that was previously unthinkable — and great ideas can come from anywhere.

It doesn’t matter whether you’re a chef, firefighter, student, stay-at-home mom, or professor of economics; if you have a clever way to meet a real, human need (or want), you can create a compelling product.

But when you have a brilliant idea with little-to-no technical ability, crossing the canyon between concept and completion can feel impossible.

Even coding can seem like a form of wizardry, practiced by caffeine-fuelled 20-somethings in headphones.

Please don’t let intimidation or overwhelm stall your project before it gets started. You don’t have to know the difference between SQL, Java and Python to create something incredible.

Instead, let’s talk about how to work effectively with a freelance team or software development firm that can bring your vision to life.

And I want to share some interesting insights from the other side, as co-CEO of a software development firm called Appster.

Each stage of your project will bring common pitfalls. Here’s how to avoid them.

Planning and documentation

I can’t overemphasize the importance of upfront project planning.

Software development is not like hiring the neighbor’s kid to mow your lawn. It’s more like a desert trek, with a series of dangers and irritants that will inevitably pop up along the way.

And the best way to de-risk that trek is to have a thorough understanding of what you’re trying to build, before you build it.

Pitfall #1: Calling up a dev firm or contractor, describing your idea, and asking for the cost

If someone can give you an exact price tag or timeline after a five-minute phone call or a single email, they’re setting you up to fail.

If they’re ready to dive right in, that’s also a massive red flag. Every digital product has a huge range of functional and nonfunctional elements that must be mapped out from the start.

No one wants to have a conversation that includes, “of course it was supposed to handle over 10,00 users per day!” — and a strong upfront planning process is the way to avoid this crash-and-burn scenario.

Pitfall #2: Going too agile or too heavy

As with most things in life, useful documentation is a matter of balance. Some agile dev experts believe that working software always beats feature documentation, but moving too fast can mean skipping essential details.

Atthe same time, a 600-page project brief with no room for uncertainty or change will only weigh you down. Find your happy medium and ensure your app or product brief outlines:

1. Non-functional requirements

• Security: Are you interacting with the Bank of England or building a flashcard app? Every product should reliably protect users, but there’s security and then there’s SECURITY. Where does your app land on that continuum?
• Performance: Does your community aspire to Facebook-level membership or will it always have less than 100 users at any given time? Performance should scale with usage loads, and finding the sweet spot where you’re not over- or under-built takes skill and experience.
• Maintainability: What language is your app built on? Can others take over the project and manage technical changes down the road? Your team might seem tight now, but you never know how personnel shifts, acquisition or investment money can affect who’s working under the hood.

2. Functional requirements

• Core features: What are your essential, must-have, differentiating features?
• Functionality: How do the features work? What do they need to do?
• Business logic flows: If you’re selling something, for example, your product needs to intersect with payment and distribution functions. How does each piece of the transaction unfold? What is the user experience from start to finish?

Pitfall #3: Fully delegating your project requirements

Strong development firms should help you with the project brief. They will have digital architects and business analysts who write technical documentation for a living.

If you’re working with freelancers or a smaller firm comprised primarily of developers, it’s important to write the brief yourself and ensure everyone’s on board.

Whatever your situation, stay on top of the documentation.

Keep your eyes on it, review it at every stage, and never assume that anyone “just knows” what you’re thinking. What seems logical to you might be new to someone else. Providing more detail is never a waste of time.

If in doubt, spell out the screen, feature, button or project element, clearly, in the scope of work.

Remember that a good software company will also look for gaps in your brief and challenge any assumptions, issues or potential snags they find. That’s a good thing. It means they’re smoothing your way to a successful build.

Testing and prototyping

Pitfall #4: Failure to prototype

Repeat after me:

Prototype early. Prototype often.

It’s always smart to put a working prototype in the hands of your users during the design process, but it’s especially important if you’re a non-technical founder.

Don’t wait until the end of development. No one wants to realize that 95% of users can’t log into your app or the news feed is confusing once all the coding is done.

As the founder and creative genius, you’re a power user.

Now you need the big-picture perspective that only comes from getting real people into your app, tapping buttons, and messing around with the features that feel intuitive to you.

Pitfall #5: One-dimensional product testing

Whatever you’re building, testing should never be an ad-hoc process. It should be planned, scheduled and outlined with two different approaches:

1. Manual testing

In manual tests, one person downloads the app, runs through all the different screens and user flows, and documents any issues or opportunities for improvement.

This tester should be working through a clear list of scenarios: i.e. “I tap button X and X should happen. Pass or fail?”

Don’t forget about environment and geography — especially if your app uses location services.

Seeing top-rated restaurants in China isn’t exactly helpful if you’re hungry in L.A.

Testers should also consider how different networks, internet connections, and technical service providers could affect what users see.

2. Automated testing

Working through every scenario can be time-consuming and expensive if you have a BIG app. Maybe your product has 400 different screens or thousands of business logic scenarios.

In this case, automated testing can be a lifesaver. It runs through basic screen functionality, crash reporting, and even how the app works on iPhone 5 versus iPhone 6, for example.

Automated testing can be seriously helpful, but it does come with additional costs.

If it’s essential to your project, make sure it’s covered off in the plan and the dev firm builds the necessary automation scripts right out of the gate.

Quality assurance

Anyone can tap some prototype buttons and see if the screens work.

But if you’re not a developer, how do you know if you’re getting good quality software? How do you know if the developers are writing useful, elegant code?

The proof is in the product. If the code is sound, the app should work.

Pitfall #6: Waiting until the end of the project to see working software

Your development partners should show you functional software and allow you to download and demo your product every two weeks — minimum — and ideally, every week.

Get a version on your phone and play with the features as the app is being built. A firm that insists you need to wait is not playing their cards fairly.

Don’t wait until the beta release is ready. Seeing early versions enables you to course correct if a feature has been implemented incorrectly or user feedback suggests a different approach.

Catching an error just one week, versus 3–4 weeks into the build, will save money, time and a lot of re-work.

Pitfall #7: Not reviewing your code during the build

Reviewing code when you’re not a developer might sound like checking your mechanic’s brake work. Yet, it’s possible — and important.

1. Manual code review

This review is usually done by a senior developer, technical architect or a team lead — someone with deep experience who’s fluent in the development language, but who didn’t write the source code.

The reviewer will check for syntax, structure, standardization, and other important details.

Manual code reviews should happen regularly, throughout the project.

2.Static code review

Think of this step as spellchecker for your code.

There are several open source and commercial tools that run automated reviews and flag security issues, non-standard practices, and other problems.

Even if you don’t have the chops to perform these static reviews yourself, the development team should regularly run the automations and share the results with you.

Work consistent code reviews into your project agreement and make sure you get the results at every phase.

It’s important to weave these details into the plan, because most firms won’t release your source code until the final bill is paid. If you negotiate regular access, however, you can ensure the app is on track.

You can also request an independent review from an outside firm or another freelancer; someone who isn’t invested in the project and can provide objective feedback.

Other important considerations

Manage the project brief, prototype, testing and coding phases with care and you’ll be in good shape for launch.

Here are a few more tips and app-building advice to help your project flow smoothly:

• Implement a daily or weekly stand-up meeting to clear impediments
  Just 15 minutes can do the trick. Your dev team may have questions that you can answer fast to keep the wheels turning. Book a recurring time slot on your calendar and stick to it throughout the build. It’s amazing how many hurdles you can eliminate with a quick verbal or video check-in.
• Stay calm and collected
  Basically, do everything you can to keep your shit together — even if the project gets stressful. We all want to work with people we like and who treat us with respect, so don’t take your concerns out on the dev team. If something is seriously going off the rails, talk to the project manager. Find a solution together. And there’s always a solution if you get creative and strategic.
• Manage your own team dynamics
  Want to drive your dev team crazy? Switch up the decision-maker from one day to the next. It’s amazing how quickly this misstep can cause project meltdown. If you’re not a solopreneur, designate one person who will consistently communicate with the dev team. Decide who makes the final call on tech issues. Keep your own internal flow clear and you’ll save major time and money.

Show me the work

If you’ve reached this point and decided you do need a technical co-founder, that’s cool. It’s probably a smart move. How you go about finding this person might depend where you are in the process.

It’s always easier to attract a technical partner when you’ve actually built something, because it shows that you’re more than an “ideas person.”

You have the drive and discipline to take action. Hearing “hey — I’ve got a killer idea! You do all the hard, technical development work and then we’ll get rich together” isn’t the compelling proposition that some might imagine.

If you’re just getting started, find a partner who’s equally motivated to build and refine and who shares your big vision.

Look around you. Is there someone close that you’ve overlooked? A friend or colleague who’s already in your network?

There’s a very real sense of trust that comes from shared experience and history. You can stick together when the project is struggling and share the triumph when it succeeds.

Whatever you decide, I’m pulling for you.

Roll up your sleeves, learn the technical jargon when you need to, and create checks and balances to help you along the way. Don’t let a little PHP or C# get in the way of fulfilling your big idea.