Nick: It’s fast-paced, tech-packed and ever-evolving. There’s been a lot of change in the last few years! Namely, because AI is becoming so prevalent in technology and a lot of people are using tools like ChatGPT now. In fact, most people we speak to these days have some idea of what AI is…so it’s moved from being a kind of taboo technology that people just know can do a lot of smart things but don’t really understand, to one that is quite accessible actually.
But also because of the advance of low code, if you've got a design for a mobile app, you can in theory ship a fairly simple build in a matter of days or weeks now. So typically both the client and users expectations have increased.
Nick: Obviously AI is being used to write code and content and so on now, and along the way other low code and no code tools have emerged too, and they bring with them challenges for an agency like ours, who largely build bespoke. These tools enable folks to create digital products without actually having to write any code. There are definitely limitations with that. But it's a really interesting time to be a digital product company, because we're trying not to see these tools as competition, but more as opportunities: how can we utilise them to improve our solutions, and the pace of development, for our customers.
Nick: Since Apple opened up the App Store to third party developers, apps have become more and more sophisticated in terms of what they can do, and the user experiences they offer. And as such, users and clients have incredibly high expectations of what is possible in terms of product, which I actually think is a good thing. For example, we have clients who expect to be able to drop WhatsApp-style messaging technology into their products, but Whatsapp (owned by Facebook) has been around for more than 10 years and has a huge engineering team. And at the same time, budgets are getting tighter so efficiency, and getting it right the first time, are more important than ever…
We pride ourselves on being very good at getting cross-platform mobile apps to market quickly. We're big advocates of React Native, and being able to build complex apps that run both on iOS and Android from a single code base. And because we achieve huge success for our clients by building bespoke products, we're currently exploring alternative solutions and tech stacks to increase efficiencies in development even further. A very big part of the service that we provide is user-centred design and we're not looking to compromise on that, but if we can reduce the budget by utilising say, a low code tech stack, then we can take a beautiful, delightful user experience and get it into real users hands effectively, efficiently and quickly, then we will definitely pursue that.
Nick: There's always a balance between trying to write code that can be reused for multiple apps and multiple projects. When you find commonalities in what functionalities you’re trying to achieve, whether that's a login system or a design system (i.e. one where you could potentially white label products and then roll it out with a different look and feel, but with almost no code changes). Reusable code is definitely super important and we're always - as an innovative forward thinking agency - looking to not continually reinvent the wheel. So wherever possible we try not just to build from scratch, and instead we build up our own library of code that we can use to create huge efficiencies for our clients.
However as a general rule, code can become outdated really quickly. So if you build something in the newest possible way of doing it right now, the likelihood is that in six months or two years time that code will be legacy code. It will have dependencies on old legacy libraries because of the speed of change. So to be honest, it can save you time in the short term and sometimes it can actually add on time, but that depends on how well it's written and how forward-thinking it was in the first place. So we do write reusable code, and we have libraries of components that we build into our apps that we can use for other customers. But it's not always as big of a time saving as people might think.
Nick: Yes, tech stack selection is really important. At ASquared, we are big fans of React, Typescript, Node JS, and lots of modern programming languages on the front- and back-end. However, as we matured as an agency, our primary focus has been on user experience, and the product that we're building. So we're not just going to use React Native because we’re great at it, if it’s not the right tool for the project. And I do think that's something which stands us apart from some of our competitors.
It's very common that a tech agency will try and sell you the tech that they are experts in, and it’s not always fit for purpose. We've actually worked with a number of clients recently that have had that kind of experience where the wrong technology has been chosen mainly due to the preferences of the agency they engaged with, and that creates challenges further down the line, especially when it comes to innovating.
For example, if you focus on the tech stack instead of the user experience then you could roll out products that cost tens or hundreds of thousands of pounds that there's no user case for, and then you've got to innovate and be agile. If you’ve chosen a tech stack that's quite limiting, that’s tough. And if your competitors are using some other stacks, they might be able to be more reactive. That’s why we'll very often recommend React Native, which means writing one code base for iOS and Android, instead of maintaining two code bases.
The argument against doing this is typically that you've got to write in the tools that Apple and Google gave developers to build their products because the quality of the product, and the optimisation available was always going to provide a better user experience. But with the technology available now, plus the speed of devices and the way that most people are accustomed to using them these days, I think that argument falls short. Unless you're building something that is very hardware specific, or reliant on GPS chips and location data. But the joy of React Native is that it actually gives us the best of both worlds, so it allows us to work on one code base and dip into the native layer when required.
Nick: Compromise is definitely something to embrace when you're building digital products, especially apps! A common challenge is a lack of alignment between design and development. You might have a designer who has limited knowledge of the capabilities and limitations of designing for iOS or Android, or a touch interface, and they might try and design something with quite a bespoke look and feel that might look beautiful, but might feel really alien for a user. So what we try to do is to have alignment between devs and designers right from the beginning of a project.
Our typical process includes a design and discovery phase which isn't about writing code at all. It's about understanding what the user’s needs are and what the business goals are. And actually, bringing developers in at that early stage and having them working alongside the designers means that instead of immediately thinking about tech stacks, they’re thinking about solving problems and offering up solutions which provide huge efficiencies later on.
We are also big fans of prototyping. We use modern design tools like Figma that not only allow you to create reusable design components and beautiful interfaces, but also to create interactive prototypes relatively quickly. You can then test them with real users to validate or invalidate your assumptions before moving into development. Ultimately you’ll end up with a better product and be punching for the five star reviews, because you’ve had the opportunity to test and tweak it.
We’re an agile thinking agency. If you took a particular graph and you had effort along one axis and impact along another, there might be a whole ton of features that the client expects and wants to be in their product. And what we typically do is as we get further into the design process, we work with them to estimate the effort that's required for those features. Because we're aligned with their business goals and user needs, we are able to make some kind of assessment with them about whether it really is a must have, a should have or a could have - some kind of clear prioritisation about the kind of impact that feature will have, and then balance that up with the amount of effort. Obviously a lower effort, high impact feature has got to be in the first version of your product.
Nick: It's virtually impossible to future proof your app until you put it into real users hands. You may be susceptible to ‘the mom test’, which is a well-known theory about getting validation from your mum (from your friends and family) that you're building something everybody's actually going to want. But you obviously need to be quite cautious about relying on users you have some kind of relationship with. You've got to talk to your actual target users as early as you possibly can. And if you don't have a product, you've got to talk to your future users, and you've got to figure out what that product is. What are their pain points? What about your app is going to help make someone's day better? And you need to think more about that than what the features are. If you can get to the bottom of that - and you can only really do that properly and make good assumptions by talking to your true users - then you can test your prototypes with them and interview them. Essentially it’s got to be more about the users than the features.
We are advocates of the MVP approach, the minimum viable product approach (or MLP - minimum lovable product!), meaning, taking all of those must haves from your feature list and prioritising them so that it's not going to take you forever to launch your first version. We’re not fans of shipping something that doesn’t feel finished but whether you're onto something or not, you can then pivot and you change and you can only do that once it’s in the real user's hands. So the MVP approach means low risk, low effort: as low as possible to get to market quickly.
Nick: It very much depends on where the startup is in their own journey. But I highly recommend owning your products and being very careful not to outsource the process cheaply. Some of the best projects that we worked on where we’ve actually added the most value have been for startups who have already gone through the process of launching that very first version and witnessed the challenges with doing that. It's very difficult to succeed with a product that people want without starting out strongly. As I said, users have super high expectations of every digital product download, so my advice is don't jump into feature lists. Focus on the user's pain points, question everything and really do your research. Essentially see it through the eyes of your users and do anything you can to get your product to market and in real users hands as soon as possible. And do it properly the first time, rather than doing it twice.
Need some help getting your digital product to market? You’re in luck. It’s a path well trodden for us over at ASquared (and we’re pretty good at it). Contact us to get started today.
Let's see what we can make together.
From startups to scaleups and enterprise, we're always happy to talk to impact-focussed and ambitious organisations. Use our quote creator to get a better idea of scope, timescales and next steps.
