Great Products Consulting

Category: Develop (Build, Design)

  • What is Technical Debt?

    What is Technical Debt?

    As your developers are building your online platform or mobile app, you might acquire something called “technical debt”. There’s a chance that you’ll never be told about it – and you won’t even know what it is, so I wanted to write this article to make you aware of its existence.

    What is technical debt?

    There is no single way to build a platform or app. Like writing an article, people will approach it in different way, and as a result, the final output will achieve the same result but actually look different.

    The choices made during development – either by accident or deliberately – create technical debt. Technical debt is the amount of re-work that you may have to do to your product in the future to get the functionality that you want.

    Why does it happen?

    There are lots of different reasons why technical debt gets created. Here are two that you’re most likely to come across:

    1. Initial decisions related to the overall technical approach
    2. Incomplete or changing requirements

    Both of these can create technical debt that has a great impact on your future plans.

    1. Initial decisions related to the overall technical approach

    Usually, you’ll make a deliberate choice about how you will develop your platform or app.  The overall approach taken can create technical debt.

    For example, one way to build an online platform is to use an existing platform as the basis for your new product. Wordpress is a common approach. Alternatively, you can have a completely customised solution. They may both give you the functionality that you want, but there are pros and cons for each. For mobile apps, the decision is often between using a hybrid platform or building from scratch as a native app.

    This technical decision is often based around money. You want to spend the least amount of money possible to get you to market, so that you can start making money. There are other factors too, but most will boil down to the initial costs and development time.

    2. Incomplete or changing requirements

    Developers can only make technical decisions about what they know right now. If you don’t have a complete picture of what you want, or if you add or change something down the track, then there’s a risk of creating technical debt.

    The developers will craft a technical solutions based on the requirements that you give them. If you’re thorough in defining what you want your product to do, and all of the nuances around it, the developer now has more information to work with.

    Imagine you tell a builder that want a single-storey, two bedroom house – and then halfway through you decide you actually want a 2-storey house. All of a sudden, the builder has to change the way in which the house is built. Some of what has been built may stay the same, but there’s a chance that some stuff may have to be ripped out and re-built.

    What does it mean for you?

    Some technical debt cannot be avoided. You don’t know what you don’t know. That becomes part of the cost of doing business.

    Another part of technical should be a conscious and informed choice that you make. You may choose to go with one option because it gets you to market sooner. This reflects the uncertainty associated with building new products.

    The final part is something that you can avoid. Be clear about what you want. Especially with an agile development methodology, developers focus on what’s immediately ahead of them. It gives you some flexibility to change your mind. However, it creates technical debt. The best case though is for a developer to be aware of what you want from the very beginning. Any re-work is a cost to your business, and it’s money that you could spend elsewhere.

    With your new awareness of technical debt and how it is created, you should now be able to start a conversation with your developer that allows you to make informed and deliberate choices about your future platform or app.

     

    Are you ready to turn your good idea into a great product?
    My idea to launch checklist is your plain-English guide to getting there.
    It’s available now for only $24.
  • Agile – The buzzword for software development

    Agile – The buzzword for software development

    Everywhere you turn these days, people are touting the virtues of agile. Large corporations are adopting it in droves, and you won’t find a IT-related job spec that doesn’t ask for it. But what does agile really mean, and should you really care?

    When you want to get a website platform or mobile app built, your developers are most likely going to tell you that they use “agile”, as if it should be this massive selling point for you.

    It is and it isn’t. In this article, I’ll explain why and also explain what it means to you.

    What is agile?

    Agile is a software development methodology. It’s mainly an approach that developers use to build websites, apps and other complex technology systems. There are different types of agile too. You might hear words like Kanban or scrum. These are different ways that people implement agile.

    What does agile involve?

    Agile is about people working together collaboratively – all at the same time – to define, design, build and test software. In true agile, this means you, developers, designers and testers are working together on a daily basis to get your platform or app built.

    The idea is to build quickly and deliver often.  It’s meant to reducing your immediate upfront costs, so that you can get your product into the hands of real users as soon as possible. This allows you to get feedback on your product; which in turn, helps you to decide what features to add next.

    Sound good? What’s the catch?

    1. Only the development team is involved

    Generally, when developers and agencies talk about agile, they’re only talking about their team – not you. This means that you don’t end up being involved in the day-to-day, and as a result, you sometimes only end up seeing something at the end of each delivery – after it has been built. As a result, you lose the collaboration and synergies that come from working with someone on a daily basis.

    2. The potential for rework

    Unless you’re involved in the day-to-day development of your platform or app, or you receive a wireframe for each screen in it, there’s a good bet you’ll end up having to pay for some rework.

    This is because you won’t get a document that gives you a complete view of how your product will work. You’ll probably see bits and pieces as the project progresses, but you won’t get a whole end-to-end view until the project is done. This means that things might need to be re-visited, and re-worked as your project progresses.

    Also, when your developers don’t have a full view on what comes next, and they’re building under short timeframes and tight budgets, you can end up with something called “technical debt”. This means that the system has been designed to deliver what you want today, but it may not be the best way to do it, and it may leave you with a bunch of rework to do down the track.

    3. Inaccurate estimates

    The idea of agile is that you want to be flexible, and spend your time doing rather than documenting stuff. That’s not to say that there’s no documenting. It’s about being smart about it. You don’t spend writing a massive document with everything that you want the product to do, and there isn’t a massive document showing you how the developers have designed your product.

    Instead, you start with something high level and expand it as the project progresses. However, without these documents, it’s very difficult to get an accurate estimate for how much it will cost to build your whole platform or app.

    Developers and agencies get around this by having a bit of a discovery period.  Here, they try to understand as much about your business and your product as possible. This (hopefully) gives them an opportunity to give you a more accurate estimate. However, there will still be a lot of detail missing at this stage, so you should expect them to ask for more money down the track.

    Where does that leave you?

    All of the above gets in the way of developers being truly agile. However, the alternative approaches for development, such as waterfall, have their disadvantages too.

    I believe agile truly works best when you’re not paying by the hour for your developers, and when you’re working hand-in-hand with them to ensure that your vision is transferred to them.

    The overall message is to be informed and be prepared. You want to be able to understand how the methodology works and how your developer plans to use it. This will help you to know what to ask for, and to get the confirmation you need that they are building the product you envisage.

    Looking for a developer?
    Get my 10 essential tips for hiring the right developer for your project.
    Download it now for free!
  • What’s the difference between Web Design and Web Development?

    What’s the difference between Web Design and Web Development?

    Do you know the difference between web design and web development? I often see people looking for recommendations for one or the other, but did you know that when you’re building an online platform or mobile app, you might actually need both?

    Traditionally, these two disciplines were quite separate and distinct. However, over the years, the line between the two has been blurred.  In this article, I’ll talk about both of these terms, and how they might impact your product development project.

    Web Design

    As it implies, web design primarily looks at how the site will look. Think colours, fonts, images – the general look and feel. It also considers the usability of the site. However, web design is now also so much more – which is where the confusion occurs.

    Web designers can also build websites. This often includes the marketing-focused websites that we all use for our businesses. The ones that explain who we are and what we do – these are called “static websites”. They can do this with the help of website platforms (or content management systems) like Wordpress and Squarespace, which usually have drag and drop website builders. These are further enhanced by “themes” that are essentially templates of “pre-built” websites. These allow designers to use their design skills to craft a web page for you.

    To even further extend the power of web designers, are “plug-ins” or “apps” that are essentially pre-built tools, which interact with the website to give it extra functionality. They allow you collect email addresses, and send them to your email marketing or CRM tool. They can also be as sophisticated as allowing you to have a membership section or accepting payments.

    A good web designer will also have some SEO skills as well. As a marketing tool, your static website should be easy to find through search-engines.

    Web Development

    Even with the increase in the scope of work that a web designer can cover, there are still limitations to what they can do – unless they really learn how to code. While most web designers will be able to do some front-end coding (using HTML and CSS), these programming languages focus on how things look on the screen. In order to do more complex things – you need a web developer. 

    Web developers have a different skill set. They can build a much more dynamic website that can capture information, store it, and do something with it. Developers can build applications that allow you to move and manipulate objects. All of the website builders, themes and plugins were built by developers.  This means that web developers are in a much better position to build a more specialised platform; with unique or specific features.

    Why do you need both?

    As you can see web designers and web developers do very different things. While they can both build you a website, it depends on what kind of website you want.    

    While a web developer can build you a static website, it might not look very good. This is not what developers are good at. However, if you want to introduce automation to your business, or to extend your business offerings through an online platform, then a developer is more likely to be able to help you.

    If you’re building a new online platform that you want to market and sell as a product, then you’ll probably need both. A web developer will build your platform – with all of the screens and components that you need to give you the features that you want. Meanwhile, the web designer will create the static website that you need to market your platform.

    But there’s more…

    Unless your web developer has some interface design (UI) and user experiences (UX) skills, you’ll also need one or more people to make your platform look nice, and to make it user-friendly. While, a web designer might be able to create a visual design for your platform, they may not have the skills and experience needed to design the user experience.

    The next time you’re thinking about who you need to turn your idea into a product, along with UI and UX designers – consider both web designers and web developers.  If you’re very lucky, you might find a superstar that has all of the skills outlined in this article! 

    Looking for a developer?
    Get my 10 essential tips for hiring the right developer for your project.
    Download it now for free!

  • 5 Foundations for non-tech people with platform or app ideas

    5 Foundations for non-tech people with platform or app ideas

    Software technology projects can be tough at the best of times, but what happens when you have an idea for an online platform or app,  and you’ve never done anything like it before?  In this article, I’ll explore some of the ways that non-technical people can get the foundations to set themselves up for success.

    As someone that’s been in the industry for a while, I can tell you that there’s no such thing as a “perfect” development project. However, if you come from a non-tech background, there will be things you just don’t know about, and frankly, it’ll make life more difficult for you. 

    Here are a few ways that you can get on the right foot:

    1. Understand the process
    2. Learn how to brief your developers
    3. Know what to build
    4. Keep on top of your development project
    5. Don’t forget the biz

    1. Understand the process

    Software and software-related product development processes are beasts in so many ways. The scope of knowledge and experience that people working in the industry have can be outstanding. Every day, I am awed by what people know and can do. So much goes on behind the scenes of tools, apps and applications that you use every day. This is not a journey where you can close your eyes and hope for the best. 

    While it’s not feasible or even necessary for you to become experts in this area – that can only happen over time – you should at least understand how the process works. You want to know what’s ahead of you and what’s expected of you. If you know how things are supposed to work, you can recognise when things are going wrong.

    2. Learn how to brief your developers

    A critical step in any product development process – not just a software one – is defining what you want (a.k.a writing requirements). When building online platforms and mobile apps, this is particularly difficult.  You have to describe your product, in detail, to someone who thinks in a completely different way than you do.

    Even the most basic digital products includes multiple features and functions. You’ll need to tell your developer what you expect each of those things to do. This means you have to become the expert on your product. There are many pitfalls and considerations when you write your requirements, and a non-tech person, you just won’t know what these are.

    Bottom line – if you can’t brief your developers properly, you won’t end up with the product that you want.

    3. Know what to build

    Along the lines of briefing your developer is actually understanding what you should be building. In software, you have an opportunity to test and learn.  

    As someone that’s not familiar with a very complex process, this presents a unique risk-mitigating option for you. Instead of pouring tons of time and money into an all-singing and all-dancing product, that may or may not make you enough money to pay off your investment – you can build it piece by piece. By knowing what to build, you have a greater chance of scaling and growing a product that people actually use. Ideally, you want to aim for the smallest possible product first.   

    4. Keep on top of your development project

    Once your development project is up and running, you can’t just sit back and wait for the finished product. Ultimately, as the owner of  your product, you want to make sure your developers are doing their job. You don’t want to wait until the end to find out what they’ve built is not what you expected.

    There are also lots of things along the way that can derail your project – both in terms of budget, schedule and what is delivered. Look for ways to be involved in your project. This might include regular status reports or meetings, design documents, sample screens, etc. If you can head potential minor issues before they become major problems, you’ll save yourself a lot of headaches.

    5. Don’t forget the biz

    Development costs are going to be one of the highest, if not, the highest cost that you’re going to have to get your product to market. The problem is, this often makes people forget about all of the other things that are needed to launch. 

    There are legal considerations around terms and conditions, and privacy. Make sure you protect yourself in terms of insurance and business structure. From an operations point of view, you also have to think about how to support your product – how will people contact you if they have a questions or a problem. An online platform or app is a 24 x 7 business so you need to think of the best way to handles inquiries. 

    The point is that your product is more than the platform or app you want to build. Products are often successful because of all of the other things that are needed to make it work.

    The bottom line

    Non-technical people build platforms and apps all of the time. 

    Sure, it would be less expensive if you were a developer, but then you probably wouldn’t have all of the other skills needed to launch and grow a product. 

    Gone are the days when you hire a developer, and trust that you’ll end up with what you want at the end. In these competitive times, knowledge is power. The more you know about software and product development, the more power you have to control your destiny. 

    Looking for a developer?
    Get my 10 essential tips for hiring the right developer for your project.
    Download it now for free!
  • What’s the Difference between UI and UX?

    What’s the Difference between UI and UX?

    This article is going to look at the topic of UI and UX. These two similar, but very different terms are often confused, and so I thought I’d take a moment to clarify.  At the heart of it, the difference lies in what each of them aims to accomplish. User interface (UI) is about aesthetics – making the system look good, while user experience (UX) is about a good (or great) customer journey through your platform or app.

    User Interface (UI)

    User interface is specific to what people see on the screen – colours, fonts, and styles. It also related to a persons interactions with objects on the screen, like buttons, links, tabs and scroll bars – the things that people click on or touch to use the system. 

    User experience (UX)

    User experience is all about how the user interacts with your platform or app. How do they complete tasks in a seamless and pleasant way.  It also extends to their whole experience when interacting with your business – from the time they find out about you, to when they buy and beyond. 

    True user experience goes back to the customer’s problems, need or goals. What are they trying to achieve and how does your platform help them to do that? Can your users solve their problems efficiently and effectively? How does your platform or app make it seem easy to solve their problem? At the end of the the day, it’s how they feel about your product.

    Great UI does not always mean great UX

    Icons are a great example for showing the difference between UI and UX. Icons look great from a UI point of view. A little picture to represent a feature or object instead of text. However, they’re not always that great from a UX perspective. 

    Some icons are universally recognised – a garbage can for “trash” or “delete”, or a magnifying glass for “search”. However, if you start creating icons for new functions that people don’t recognise, and they have to learn what that icon means before they know whether they want to use it or not – then you’ve created a bad UX. 

    But there are overlaps too…

    Let’s take a button as an example. 

    In UI, you look at the colour, shape and size of the button. You also determine the font, size and colour of the text,  as well as the location of the button on the screen relative to other elements. Sounds a little like UX doesn’t it? The way the button looks will also make it easy (or difficult) to use. Imagine a button so small that your thumb or finger can’t click on it, or one buried at the bottom of a page amongst some text where you can’t see it. 

    There are some UX pieces to this button as well. When your cursor clicks a button, it might change colour so that the user knows that the button has been clicked. Maybe there’s a tool tip when you hover over it to tell you what clicking the button will do. These UX elements can make your platform or app more user-friendly. 

    Hopefully, you’re starting to see how people can get confused between UI and UX. 

    Why you need to know the difference between UI and UX

    As you look at how to get your product built, you need people with good UI skills as well as good UX skills. Some people have both skills, but some don’t, so you want to understand a person’s capabilities before hiring them. Even if you go through an agency, it’s worth your time to find out how they deal with UI and UX. 

    Bottom line – things may be visually appealing and perform the function intended (good UI), but the user shouldn’t be frustrated because they can’t figure out how to use the function (bad UX). It turns out the two need each other if you want to make a great product, so keep that in mind as you head out on your development journey.

    Are you ready to turn your good idea into a great product?
    My idea to launch checklist is your plain-English guide to getting there.
    It’s available now for only $24.
  • What is a Wireframe?

    What is a Wireframe?

    A wireframe is a drawing of a screen as it might appear on a website, an online platform or a mobile app. Wireframes are very powerful tools for describing what you want to build, and for illustrating your idea. In this article, I’ll explain the different types of wireframes and how you can use them to create your platform or app.

    On the web and on mobile apps, screen design plays a key role in how your customer and users interact with your product. These designs are usually created by user experience (UX) designers; often with the input of graphic designers (some user experience designers have visual design skills as well).

    Wireframes in Product and Software Development

    Traditionally, screens would have been envisaged in the “design” phase of the development process. Developers and designers would sit together to determine how a user will move through the application, and what the screens should look like.  However, screens can play a vital role in explaining what a product should do. As a result, screen designs are edging their way into earlier phases of the software and product development processes.

    As you’re validating your idea during the “analyse” phase of product development, wireframes can used to test your product idea. You show the screens to potential customers so they can understand what you’re trying to do and what the product might look like. The screens can even be linked together so people can ‘navigate’ through a particular feature. The feedback is invaluable in terms of seeing how people interact with your idea.  You can also get their reaction to your solution and whether it solves their problem.

    In terms of defining your product (the “define” phase of product development and the “requirements” phase of software development), wireframes are a great way to illustrate to developers what you want your product to do. In some cases, people get UX designers involved here to get some detailed wireframes outlined before starting development. However, be aware that there’s often a strong dependency between what the screen looks like versus how things work behind the scenes. In some cases, the designed screens may have some technical constraints, so you might have to re-do some of the screens at a later date.

    Types of Wireframes

    Wireframes come in different levels of detail and each one of them has different uses when creating your product:

    1. Low-fidelity wireframes

    These wireframes are hand-drawn and very high-level. They show the overall placement of content on the screen using boxes to represent areas of content, and lines to represent text. These are often used to map out what screens are required, the flow of the screens and the high-level content (e.g. picture, text, button, menu bar, etc). The idea is that you don’t want to spend too much on the detail. You’ll use these “lo-fi” wireframes in the “analyse” and “define” phases as you’re just illustrating concepts.

    2. Medium-fidelity wireframes

    Lo-fi wireframes are converted into computerised images with software tools like Sketch or Balsamiq or even basic drawing tools like PowerPoint. The high-level content is replaced with additional details – such as what type of picture will be displayed, what content will be included (e.g. contact information, user registration), etc.

    3. High-fidelity wireframes

    High-fidelity (“hi-fi”) wireframes often look like graphical representations of the actual screens. User experience designers will provide actual fields on a form (e.g. field labels, field types – calendar, drop downs, radio buttons, etc), general spacing and navigation. Graphical or visual designers will fill in the pictures, colours, font types, logos, styling etc. Items on the screen are annotated to include design and development notes (e.g. click here to go to the home page).

    The diagram below shows the level of detail in different types of wireframes:

    In many cases, people don’t bother with hand-drawing screens, go straight to the computer, and call them lo-fi wireframes. Some people will skip that step altogether, and go straight to hi-fi wireframes. It doesn’t really matter what you do – it’s more a matter of how much time and money you want to spend on it. It’s much quicker to hand-draw something rather than to put it on a computer. If you end up with multiple iterations of your screens or end up with new screens altogether, you spend less time and money doing this when you’re drawing boxes and lines versus very detailed screens.

    It’s important to remember that during “analyse” and “define/requirements” activities, wireframes should be focused on “what” rather than “how”. You don’t want to restrict your developers by telling them “how” you want something done.  Wireframes should be used to show them “what” people should be able to do, and the outcomes or benefits they expect from using your product.

    Why should you care?

    Depending on your budget and skills, you need to determine whether you want to create your wireframes or get someone to do it for you. You may want to draw low- or even medium- fidelity wireframes, and then pass them on to a designer. Alternatively, you may decide that your strengths lie elsewhere, and you hire a designer to do the wireframes from scratch. If it’s the latter, then you’ll still need to provide some guidelines to your designers, and this can be done in your product definition.  This instructs the designer on what the product should do.

    Either way, knowing how to draw wireframes, and understanding the different levels of detail are important skills to have. Pictures are a very powerful communication tool, and can be used throughout the development process to show developers what you want them to do.

    Are you ready to turn your good idea into a great product?
    My idea to launch checklist is your plain-English guide to getting there.
    It’s available now for only $24.
  • Get from “idea to launch” with my new checklist!

    Get from “idea to launch” with my new checklist!

    If you’ve got a great idea for an online platform or mobile app, but you’re not sure where to start – you’re not alone. Tech can be intimidating for those that have never had any experience with it before. Sometimes you want someone to guide you through the process – but you just can’t afford to hire someone to help you.

    The good news is that building an online platform or mobile app is a process.  This means there are clearly defined activities that you can follow to reach your end goal. Once you know this, the whole thing becomes more manageable – you just have to take it one step at a time.      

    Introducing the idea to launch checklist

    Today, I’m pleased to introduce the “idea to launch checklist”. This downloadable checklist contains “must-know” tasks in 15 core areas, so you can turn your good idea into a great product. It provides a plain-English roadmap for your journey. You’ll see the main activities for developing a product, and the tasks involved in each step.

    The idea to launch checklist came about as a way to take non-technical people through the creation of a digital product. Like the design and manufacturing of any product or service, platforms and apps have their own brand of jargon and their own unique complexities.  This checklist needed to be written in a way that anyone could follow.

    I understand that not everyone wants to be an expert in software development. Business owners and working professionals certainly have enough things to do and learn! This checklist has been designed with you in mind. If you’re serious about building your own digital product, then the information in this foundational checklist is definitely in the “need to know” bucket. 

    Did you know that on average only 16.2% of software projects are completed on-time, on-budget and with the features and functions originally requested?

    Having worked on technology projects for almost 20 years, I’ve learnt a lot about software development – to a point where it’s mostly routine and I don’t have to think about what to do. Throw in 8+ years in product management, and there’s all of this experience that I took for granted.

    It made me realise that this lack of knowledge is costing people money.  I’m sure people would learn a lot from their experience, but I think they would prefer not to spend so much money on those lessons!

    As someone that’s been doing this for so many years, I really want to help people avoid this situation. So, I’m sharing my experiences and knowledge with people that have had their “light-bulb” idea, and are ready to do something about it.

    Here’s a taste of what you can expect from my checklist:

    • 21 ways to evaluate your idea. Let’s be real – you need to know if you’re backing the right horse.
    • 20 critical steps to finding the perfect developer. This is not the time for speed dating.  A bad decision will cost you time and money and could even delay your product going to market.
    • Plus 25 tasks that will ensure your product testing is rigorous and effective…. If you’re really going to do this, you want to do it right.

    Think about it – you can’t ride a bike the first time you try it. In fact, before you perfected riding on two-wheels, there’s a good chance you rode a tricycle or had training wheels. You also probably fell a few times.  Maybe you could only make it to the end of the driveway before putting your foot down. Eventually though, you made it to the end of the block and around the park a few times.  

    Building digital products is much the same as this. That’s just the way life is. It often takes a few goes around the block before you’re comfortable with what needs to be done. You can try it with two-wheels for the first time without the training wheels, or you can get some help to make it easier on yourself.

    This foundational checklist is all about action. I want to see you get that platform or app built, and I want you to get there in a straight-line path. So, if you’re ready to build your platform or app, click here to find out more.

  • What are your options for hiring a developer?

    What are your options for hiring a developer?

    You’ve got an idea for a web platform or mobile app that you’ve decided to turn into a real product. You’ve documented what you want the product to do and you may have even drawn up some screens. So, now you need someone to make your idea into a living, breathing product. Along with figuring out how to brief a developer, hiring a developer is somewhere near the top of the list of challenges when building a web platform or mobile app. It’s such an important decision to make, but where do you start?

    How do developers work?

    The first thing is to understand the structure of the development industry. Developers can work via different arrangements:

    1. As an employee – where they work for you either in a permanent role or via a fixed-term contract
    2. As a freelancer (or contractor) – either hired by you directly or via an agency/recruitment firm; with the agency performing a mainly administrative role (e.g. billing, payroll, etc) and charging a percentage of the fee paid for the freelancer
    3. As an agency – where the agency is an outsourcing partner; offering a variety of services related to developing apps

     As a new business, you do have a few additional options:

    1. Find a “technical” co-founder – someone who will build, operate and enhance your product for you in exchange for some equity in your business
    2. Apply for an accelerator – where some of these provide development skills and business guidance in exchange for some equity in your business

    So, which one is right for you?

    There’s a lot to weigh up here and it’s not a decision to take lightly. Some considerations include:

    • How much control do you want to have in your company?  The more equity you give away, the less control you have.
    • What’s your budget?  Some options are cheaper for you than others.
    • How much do you want to be “involved” in the technical building of your app? Similar to the budget question, the more involved you want to be, the cheaper it will be.
    • What roles do you need to fill? If you need different skills to make your idea a reality, some options will act as a “one-stop-shop” for all of your development needs. 

    While these are the obvious questions, there are a few other considerations to factor in.

    What are your ultimate goals for the platform or app?

    This is an important question to ask yourself as this affects the type of developer you look for. Are you building an app to sell out at a future stage? Or are you in it to create an ongoing stream of income for yourself? 

    When you give away equity or take on investment funding, there is always the expectation that people will want to get their money back – and then some. There are people that build apps purely for the opportunity to sell it for big bucks some time in the future. This business model generally involves large-scale investment up-front with a view of not making any profit in the short-term (think of any large online platform, and chances are this is how they’ve done it). Investors and founders make their money on the sale of the product (or going public on a stock exchange).

    If you want to build your app purely to supplement or replace an existing salary, then you want to find an option that involves business partner(s) that have the same goals as you do, or you outsource to a freelancer or developer.

    Do you know anyone personally or through a friend or acquaintance that might fit the bill in any of the above categories?

    By far, the easiest way to find a developer is through a referral – either someone you know personally or someone that has a good reference from someone you know and respect. Like anyone that you might hire for your business, trust is an important part of the equation and if you can find someone you trust through your own network, it makes things a lot easier.

    There’s a caveat here – don’t trust blindly! The developer may be good at what they do, but they may not have any experience in your domain or industry. The person you know may have had good results with a developer, but others might not have. Do your due diligence to make sure that the referral or recommendation is the right choice for your project.    

    Who will make a better long-term partner?

    Knowing someone may not be enough of a reason to hire them. Building and running a platform or app is an on-going process. As I explained in Part 4 of my series on product and software development, your product will change and evolve over time. You’ll also have ongoing maintenance and support issues to deal with. This means that ideally, your developer is in it for the long haul. You want someone that isn’t just attracted to the shiny, new platform or app you want to build. This someone needs to stick around after it’s been built. There are so many stories of developers that become unresponsive after the initial launch – mainly because they want to get onto the next shiny project. It’s not always easy to find the right developer though – generally, most will already be taken by the high-paying startups or they work in large corporations.  

    Where does that leave you?!

    You most likely won’t be able to afford to hire a developer in a permanent role and if you want to retain control of your business, then most of the equity options are out. This means you’re left with finding a tech co-founder, using a freelancer or an agency.  

    There is no “best” option here. A lot will depend on the person or agency that you choose – and there can be lots of variation in quality between them. Choose carefully as picking the right developer is an important factor in the success of your development project (check out my tips article for other factors). 

    To wrap up, if you’re looking to build a web/online platform or mobile app and you can’t code, then you’ve got to put together your own development team. There are several options for doing this and you’ll have to decide which is best for you based on your circumstances.

    Want to learn more about building and growing your platform or app? Join our email list to receive regular updates

    Just curious
    Evaluating my idea
    Ready to start building
    Building my product
    Launched my product

    * When you sign up for our list, we’ll send you emails that include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you. To view our privacy policy, click here.

  • What’s scope creep?

    What’s scope creep?

    The term “scope creep” might conjure up images of spiders and other crawling insects, but it’s actually a real concept in software development. I introduced it in my article on “Tips for Building a Web Platform or Mobile App”, and now I’m going to expand on it to tell you why you need to be aware of it and how you can prevent it.

    Scope creep occurs when the size of a project increases after it has started due to the improper management of requirement changes.

    Huh?!

    Ok – say you have a project that starts with a list of 10 things to build. That’s the scope of your project. As you go through the project, you realise that there are another 5 things that you want to build. If you decide to include them in your project, your scope has grown by 50% to 15 things. That’s scope creep.    

    Why do you need to know about scope creep?

    Scope creep is an easy trap to fall into. When you’re building a product from scratch, there’s only so much that you know at the beginning. As you start the design and build process, you learn more about your product, and you think of more things you want your product to do. You want it to be perfect, so of course, you need to include it in the initial version of your product. The new requirement is added to your project – then another, and another – and all of a sudden, it takes months longer to finish the build of your product and costs you more.

    Your developers will love you! They get more money and you get the product that you want.

    So why is this bad?!

    Presumably, when you were planning to build your platform or app, you had a budget of some sort – the amount that you wanted to spend or could spend on development. Better still, you had an idea of the financials required to make your idea commercially viable (e.g. the numbers that you needed to hit to make money). If you fall into the scope creep trap, you might a) not have enough money to complete the building of your platform or app and b) your idea may no longer be commercially viable.

    This notion of scope creep also ties into my article the other week about a minimal viable product (MVP). People often have good intentions and start with building an MVP – and then they get excited – a competitor has this feature that you just have to include, and there’s this really cool feature that you think your users will love. Your initial release gets bigger and bigger, and is no longer an MVP. Also remember, that 80% of features in most applications don’t get used! There’s a good bet that many of your unplanned changes won’t materially affect your product in a positive way.

    What can you do to prevent scope creep?

    There are two main ways that you can prevent scope creep from happening.

    1. Define your product properly upfront
    2. Manage change to your product scope appropriately

    1. Define your product properly upfront

    Scope grows when you realise that there’s something else that needs to be included in your project. So, to prevent this from happening, you need to have a better idea of what you want to build upfront. This involves having a very clear, and often detailed, view of what you want your product to do. Take the time to think through every process and every function that defines your product.  You want to make sure you’ve captured different scenarios that might occur, and the features you want your product to have. This will allow you to have a well-defined scope for your project.

    The reality is that there’s going to be things that you miss – and that’s ok, because now you’re only going to miss a few things rather than lots of things. This is where the second method for dealing with scope creep comes in.

    2. Manage change to your project scope appropriately

    When you discover that there’s something else you need to add or change you to your product, then there’s a few things that you should do before you decide to actually build it:

    1. Prioritise the change: How important is it really? Do you need it in the first version or can it be something that’s added shortly after?  

    2. Get your developers to estimate the size and impact: Understand how much it will cost you to make the change, and how it will affect the overall project schedule.

     3. Evaluate the impact to your financials and business model: Use the numbers to see if you can afford to make the change. Does it affect the commercial viability of your product? Will delays disrupt your launch strategy? Do the benefits outweigh the costs?

    If you do all of this and decide the change is worth it, then go ahead and do it. This doesn’t have to be an extensive, drawn-out process. The point is that you’ve made an educated decision about changing the scope of your project.

    If you’re working under an agile methodology, recognise that your change may mean that something else doesn’t get done. This change may have a higher priority and cause another requirement to be pushed back. You’ve got to decide whether to extend your project to include the lower priority requirement or not.

    Not all change is bad…

    Despite all of this doom and gloom about scope creep, there are often very legitimate reasons for making changes to your project. The lesson here is that you don’t want to be caught unaware of what’s happening. It’s very easy to for a lot of small changes to accumulate and drive your costs up and delay your launch. So, before your start your project, be as sure of your can of what you want your product to do, and while you’re product is being developed, have a process in place so that you can make informed decisions about changes that you want to make to your product.

    Want to learn more about building and growing your platform or app? Join our email list to receive regular updates

    Just curious
    Evaluating my idea
    Ready to start building
    Building my product
    Launched my product

    * When you sign up for our list, we’ll send you emails that include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you. To view our privacy policy, click here.

    << (previous) What kind of business do you want to be
     
  • What’s in a web application?

    What’s in a web application?

    You have an idea for a web application (a.k.a app or platform), but what does that actually look like? If you think about building a house, you have a foundation, a frame, walls, a roof, plumbing and electrical wiring.  All of these things are important to the finished product.  You should think about your application in the same way.  It’s made up of a bunch of different components.  Depending on the type of application, these components will be needed to make your product work.

    Since, I’m always trying to find ways to explain technical concepts to people with non-technical backgrounds, this article is going to take you through the components of your future product.  This will help you to understand what you’re aiming to build. Mobile apps are slightly different, so I’ll look at that in another article.

     Here’s a simplified diagram of your web app:

    As I started to create this diagram, I realised that there were a lot of things we just take for granted. We turn on our phones, open up a web browser, go to a website and it all just works. It’s obviously a little more complicated than that! So, when I say a “simplified” diagram, it really is! For now though, it’ll suit my purpose for explaining some basic concepts to you.

    Some of these explanations may sound obvious, but for the sake of making sure that everyone is on the same page, please bear with me.  

    Device (hardware and software)

    Let’s start at the top of the diagram. The device (your phone or computer) is a physical piece of equipment through which you access your application. This is called “hardware”. When you turn on your phone or your computer, the thing that makes it work is called “software”. Without software, you phone is like a paperweight – it does nothing! The software associated with making the hardware work is called “operating system” (or O/S) software. The individual programs and apps that allow you to do things on your phone or computer (e.g. a web browser) are also called “software” or “applications”.

    Software is a collection of programs that provides instructions to do something and it can be written in many different coding languages. Programs themselves are a collection code used to perform a function. The code uses specific terms and formats to instruct the device on what to do – this is dictated by the coding language chosen. I’ll save a review of different programming languages for a different post as there’s a lot to cover there.

    Front-End

    The “front-end” is composed of all of the things that you see on the screen. It also includes some smarts to help you navigate the app, capture information and trigger activities within your app.

    The level of complexity on your front-end will depend on the types of things that will done via the screens. For example, if you’re just displaying information that never changes, then that’s a lot easier than a page showing search results on a map; where you can zoom in and out on the map, select an object and view information about it.

    Back-End

    The “back-end” refers collectively to the programs and data storage for an application.

    Back-end Programs

    Back-end programs do the heavy lifting – they allow you to do things like store and retrieve information, make decisions, and perform actions by applying logic to information provided by the front-end. Think of it as the engine behind what you end up seeing on a screen when you make a request for something.

     Some examples of back-end programs include:

    • Creating an new user account
    • Validating a login request
    • Retrieving a list of items based on search criteria
    • Calculating values for a report
    • Making a decision on a customer appliction

     As you can see, the back-end is just as important as the front-end. Together, they work with some sort of data storage facility to make your app work.

    Data storage (a.k.a. a database)

    Information that is captured by your app needs to be stored somewhere so that it can later be retrieved, displayed or processed at a later date. This prevents a person from having to re-enter information over and over again. The data held in the database can also be generated by the app itself. This might include things like the date the information was entered or an internal status for a person’s account.

    For web apps, data is usually stored in a centralised database where the information for your app and all of your users is held in a single place.

    There are alternatives to a “database” which is why I have termed this “data storage”. For now, the important thing to know is that data for your app will be stored somewhere and programs will be written to access and update it.

    Application Programming Interface (API)

    So how do the front-end and the back-end talk to each other? This is where APIs come in. An “application programming interface” is a program that allows two applications to talk to each other. Those applications may belong to you or to someone else.  APIs take a request from one application and provide it to another application to process. It also provides the response back to the original application. In your case, this conversation will mostly take place over the Internet.    

    Some APIs are standard – for example if you want to embed a Google map into your app or if you want to add email addresses to a MailChimp list. This allows companies to establish consistent methods for applications wanting to communicate with them. Think of them as a published manual with the available ways to contact an application and the functions you can access. This manual will also tell you how to make the request and the format that is required.

    Other APIs, like your application, may require some customised coding to work. However, for most functions, there’s probably already a template that your developers can start with to achieve the required result.

    Host (hardware and software)

    Your app (front-end, back-end and datastore) has to be loaded onto a piece of hardware to work. Otherwise, they are just letters and numbers on a page. That piece of hardware is called a “server”. It’s a physical device that has the capacity to run programs, manage all of the requests being sent to it, and store data. These machines can range in size and the specifications will depend on the needs of the application and the number of people accessing it. These servers also have software that allow you to monitor their performance and manage the content on them (think uploading and downloading files and programs, and managing security).

    As you can imagine, at the beginning, most of us will not be buying and running our own servers, so we’ll use companies that specialise in this. These companies are called “hosts”. They offer services, called “hosting” that provide the hardware (e.g. servers) and the software to run your app.

    Hosting and choosing a hosting service deserves a whole article of its own, so I’ll leave it at that for now. Basically, to make your web app work and to make it available to people, you’ll need a host.

    What does this mean for you?

    So, there you have it – the components of a simplified web application. It turns out there’s a lot there!

    It’s important that you understand all of these different components so that you have a reference point when a developer starts talking about them. It also helps you to know what you’re actually building.  Finally, you now have an idea of the types of expertise that you’re looking for when putting together your development team.    

    If you have any questions or if something about this isn’t clear, please feel to let me know in the comments below.  

    Do you need some help to make your web application a reality? Send us your details and we’ll set you up with 30-minute discovery session to get you on the right track:

    * When you sign up for a discovery session, we’ll also add you to our mailing list so you can receive emails from us (with your consent). These emails will include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. You may also receive follow-up emails in relation to this session. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you.To view our privacy policy, click here.