How are LLMs like ChatGPT going to revolutionize real estate?

How are LLMs like ChatGPT going to revolutionize real estate?

Here is how AIs like ChatGPT are going to revolutionise real estate: invisibly, by increasing efficiency in the market, and visibly, by making customer services a bit cheaper and higher quality.

AI is already in real estate, and has been for a while, but it’s not AI like ChatGPT. The AI in real estate is a collection of technology and techniques known generically as Machine Learning (ML) and it uses the same basic building blocks, called neural networks, that ChatGPT uses, but with different structures and different arrangements of the building blocks because they have a different purpose to ChatGPT. 

Trulia is an example of a proptech company leveraging the power of ML. They’ve used it to build their property recommendation engine, for predicting user engagement, and for identifying property features from photographs.

These are things ChatGPT can’t do. ChatGPT is a Large Language Model (LLM). It’s a multi-layer neural network that has been fed a tremendous amount of text and it is very good at stringing words together into sentences in response to some input text.

It has been fed so much text that it is very good at masquerading as an under-trained lawyer, a sub-par business analyst, a mediocre marketer, a hack journalist, etc, simply by stringing together pieces of the text it has been trained on. 

While being very good at generating text, LLMs like ChatGPT aren’t very good at math. You can’t use them to do things like predict user engagement or identify property features from photographs. 

So what are LLMs like ChatGPT good for?

What LLMs are good at is bridging the vast gulf between human written text and the kind of numerical inputs ML systems can deal with.

This can be as simple as basic sentiment analysis, turning a review like “This is so not the best hamburger joint in town” into a -1, and a review like “I hate how good their fries are” into a +1 – simple numbers that can be used in a prediction model.

Stepping beyond this, LLMs can be used to turn text into ranks. An LLM can consistently turn, say, countertop descriptions like “mustard yellow formica”, “granite”, “hand-poured, hand-polished concrete” into a range from 1 to 10. The real value in this is that when it sees a new description, like “clear resin featuring embedded seashells”, it can fit it into the same range.

Moving beyond simple ranking, we can combine it with data extraction. Here is an example where an LLM pulls specific data from a police report. It could just as easily be a property listing:

 

This kind of “encoding” has normally been a job for humans. This drove up the price for the production and updating of useful databases, making them expensive, rare and proprietary. Spending the money and the time to do the encoding and compile a database was a nice way to build a moat.  

But now it’s not a moat because anyone who can connect a web scraper (or web scraping service) to an API call to an LLM can fill a database with any information they want in days for next to nothing. 

So getting data isn’t going to be much of a problem any more. That’s going to bring efficiency increases. Maybe some parts of the market will eke out a few more percentage points in returns, but only if they can use the data.

Trulia, for example, isn’t running their services on LLMs. LLMs will only be part of the pipeline. The real work and real value will still be done with classic ML models fed with higher quality data encoded by LLMs. 

So, that’s the invisible part of AIs impact on real estate. Let’s now look at the likely visible impact. 

AI, LLMs and email and chat

This visible impact is going to be based on the highly visible features of LLMs – their ability to generate text and respond in a conversational manner. 

We’ve already seen too many real estate listing generators that use LLMs. That last link, agently, provides LLM generated property descriptions as one of their less important features.

This is one of the recurring gotchas of building products with LLMs. It is so easy to get text out of an LLM that whatever product idea you have, if it is just producing text then your business model is in danger of becoming another company’s bullet point.

Is AI Chat going to take over customer comms? 

Chat is the big, consumer-facing application of LLMs like ChatGPT, Bing and Bard. With the ability to train LLMs on your business’s documentation via fine-tuning (OpenAI’s page on it) or using embeddings to constrain the information an LLM can work from, it seems we can all turn over our customer enquiries to software, saving us huge sums of money. 

If only it were that simple.

The problem with using LLMs to “chat” to your customers is that you need to rely on raw text from the LLM. LLMs don’t have any judgement. They just generate text. The result is that they “hallucinate” – produce wrong or even wildly wrong responses – and there is no way to guard against this except having a human in the loop. 

If you are building your customer service chatbot on top of an LLM like GPT-4, even with fine-tuning, the data you supply (chat logs, FAQs, blog articles) will be such a tiny percentage of the LLMs “knowledge” that it will inevitably “hallucinate” when answering questions. It might even insert information from a competitor’s products (that were documented on the internet prior to September 2021).

The other problem is that prompt jailbreaks – strategically written text that tricks the LLM into leaking information or hijacks it for the user’s own purposes – are not a solved problem. 

The end result is that LLMs are not predictable enough to be trusted and so are not going to replace staff in customer service roles. Instead, they are going to act as an assistant to them. They’re going to help customer service staff find answers faster, they’re going to help customer service staff provide better answers, and they’re going to help customer service staff manage complex and ongoing interactions.

Crisp wrote up a fantastic deep dive into their efforts to add AI to their customer service. It’s not easy. It’s not cheap. It will get cheaper, but when you look at the steps they had to go through it is hard to imagine it getting easier.

Zendesk, the customer service SaaS, have also found that AI and LLMs are going to augment staff, helping to improve customer experience, instead of replacing them.   

So AI chat as it is popularly imagined – replacing customer service staff with a bit of code – is not going to happen any time soon. For anything other than the most basic and pro forma customer enquiries, where an LLM chatbot might be limited to being a high-powered FAQ regurgitation engine, humans will still be in the loop and on the payroll.

What’s Proptech going to do with AI?

That’s the big question. The AI services landscape is already fracturing into service providers who will run LLMs for you, fine-tune them for you, host your data for you, etc. AI tools are generic tools. At the coal face they work just as well for any industry, be it real estate or livestock management. So the shovel sellers are already busy selling shovels. 

Proptech startups need to be looking at what untapped data is out there, preferably in text format if you want to jump on the LLM bandwagon. That text could be in paper format. Have you noticed how good OCR has gotten in the last year or two? 

The data might already be sitting on your server. A database of transactions is a prediction model waiting to be trained. Prediction gives you the opportunity to optimise and de-risk, two things every industry wants to pay for. 

Whether you want to reduce the cost of comms with tenants or streamline nine figure real estate transactions or improve compliance in building maintenance schedules, you need to be asking yourself where you can scrape, collect, licence or buy the data you need.

That, we expect, will be easier to do than hire the data scientists you’re going to need to make it work. Maybe the shovel sellers will fix that for us.   

Building your app with an extended team

 

Building your app with an extended team

Getting Started

  1. Briefing with SoftwareSeni about the product you want to build

    We work with you to sketch out the development strategy for your app, web app or website.

  2. Decide on a tech stack based on your functional requirement

    A grid of the logos of tools used by SoftwareSeni including ReactJS, Node, FireBase, Shopify, Angular, Vite, NextJS, WordPress, MailChimp, WooCommerce and more.

  3. Start reviewing developers from our talent pool

    You start with a shortlist of talent that you can be sure have the skills and experience you need. You meet one-on-one for a video interview so you can get to know the candidates.

  4. Complete scoping and specification

    Wireframes and business rules are finalised. Feedback during the process ensures balance between budget, features and viability. Full project estimates are in place. You know exactly what needs to be built.

  5. Engage and onboard your chosen developers

 

Development begins

Weekly sessions with your SoftwareSeni product consultant and project manager keep the project advancing smoothly.

  1. Review product prototypes and give feedback

  2. Stay in the loop

    You get daily updates as well as weekly and monthly reconciliation reports so you always know how the project is tracking financially and towards your deadline.

  3. Developers integrate your product with the services your business relies on

    This includes payments, CRM, ERP, customer support, reporting, shipping, and more.

  4. Infrastructure is configured ahead of launch

    Web servers, database servers, load balancers, CDNs – all the  technical services you need are set up, tested, and placed under monitoring.

  5. Final rounds of QA are completed on staging servers

  6. Soft launch on production servers with a small cohort of beta users

    Another round of full QA is conducted to ensure there are no incompatibility issues in the live environment.

Launch!

The first version of your product goes live. Your marketing campaign goes into action. You start signing up users.

Post-launch

The first version of your product goes live. Your marketing campaign goes into action. You start signing up users.

What’s next?

OR

OR

OR

How to get your app to market faster

 

The best time to get your app to market is yesterday. Great advice. Not very actionable. More actionable: get your app into the market as fast as you can. If you know you’re already working at your limits, we’ll show you how to get your app to market faster with one phone call. It’s not a secret – a big part of it is an extended development team.

Prioritise the right features of your app to launch sooner

The first step to getting your app to market faster is focusing on the Minimal Viable Product (MVP). The MVP has the smallest set of features that will deliver value to your customers and start generating revenue for your business. 

This means at launch maybe they won’t be able to set a profile picture in the MVP, but they can login, view items and order. That’s what they really want to do with your app. And that’s what you need them to be able to do.

After launch you continue to iterate on your MVP, adding new features and improving existing functionality based on user feedback. Done right, this leads to increasing revenue and uptake of your app, making its ongoing development self-supporting.

Use an extended development team to get your app to market faster

There is a piece of folk wisdom in software engineering that says throwing more programmers at a problem will only make things take longer. This originates in Fred Brooks’ book The Mythical Man Month. Don’t worry about it. It’s true(ish) under certain circumstances. But developing a new app is not one of them. 

As an app can be divided into a front end (the user interface) and a back end (that manages databases, authentication, integration with other services, etc), as well as processes like QA, devOps and provisioning infrastructure, there are multiple focus points where specific expertise, or simply more devs, can move your app forward.

It takes deep pockets and months of interviews to build a team that can hit all these areas at the same time. This is out of reach for most SMBs unless they make use of an extended development team.

The lack of in-house talent results in a long, slow path to launch, often delayed due to missing expertise. Most programmers can learn most programming related skills – languages, frameworks, algorithms, tools – but it takes time and it takes even longer to become an expert. 

So, yes, your React programmer could optimise your database queries, but it would be faster and less error prone to hire a developer who already knows exactly what to do.

This is where the extended team comes in. Also known as a team extension, dedicated team or staff augmentation. An extended development team is a lot like remote workers but with better management, lower risk, and reduced costs.

One of the biggest benefits of an extended team is how quickly they can be put in place and start being productive. If you’re trying to get your app to market fast, this can save you months. This quick set up is made possible by the vendor you will work with.

How do you hire an extended development team?

Hiring an extended team requires a vendor like SoftwareSeni. In SoftwareSeni’s case, we use a hybrid onshore/near-shore model: your consultant is based in Australia, and our talent pool is located in Indonesia’s tech hub, Yogyakarta.

To hire your team you supply us with details on the skills and headcount that you need and SoftwareSeni provides candidates for you to interview. What can take two or three months (including negotiating salaries and paying fees to recruiters) is completed within a couple of weeks. And before you begin interviewing you already know what your costs will be.

How is an extended development team different from a remote team or outsourcing?

In this post-Covid era of Work From Home, an extended team is no different to a remote team. They show up (online). You manage them. They do the assigned work. They attend virtual stand-ups and meetings. Just like the rest of your team. 

However, unlike normal remote employees, they work out of the vendor’s premises. This provides a secondary level of management at no extra cost to you. The vendor wants the developers in your extended team to deliver exactly what you need. They also provide your extended team members with technical and human resource support functions you don’t need to fund or deal with. 

Unlike a typical outsourcing arrangement, you are in complete control and have complete insight into the work your extended development team members are doing for you. 

Move faster and do more with an extended team

An extended team lets you increase your headcount, and development pace, without increasing your budget. The extended team also provides you with a level of flexibility a normal team cannot. 

You can drop team members when their skills are no longer needed. You can add staff to areas that need more attention. All while having complete control over your budget. 

Reduce your time-to-market with a phone call

The first step in getting your app into the market faster is to speak to your vendor. At SoftwareSeni we can help you to quickly finalise team composition and skill sets based on your product goals so you can start building faster. At every step you’ll be in complete control of costs and be able to scale your team up and down to match your budget.

Contact SoftwareSeni to start building your extended team and getting your app to market sooner.

3 stats that prove mobile-first is a must for ecommerce sites

 

We’ve also thrown in a bonus 4th statistic at the end of the article on why you should care about mobile-first ecommerce. It’s a bit of a kicker. If you’re about to start on your own ecommerce website development project, this will convince you how important a consideration mobile is.  

Before we get to the mobile ecommerce stats, lets recap what happened over the last couple of year.

Due to lockdowns, brick and mortar stores had to face the reality of customers never setting a foot in their premises. There was a rush by businesses to establish an online presence.

Throw up a store. Anywhere. By anyone.  

This strategy saw mixed success. Having to compete online against giant retailers (ahem, Amazon), smaller businesses had to bring their best game. That game had to be focused on mobile. It often wasn’t. Newsflash – your ecommerce strategy still needs to have a mobile first approach.

What is mobile first?

Mobile first means your website it designed to look good and perform smoothly on phones from the beginning, and then adapted to also look good on the desktop. Phones aren’t as powerful as laptops and desktops. So if it performs well on phones you don’t need to worry about the rest. So you want your a mobile first website and you want to be a mobile first business.

Stat Number 4 demonstrates why this is important. But first, Stat Number 1.

Stat Number 1 – Page Views On Mobile

55% of page views come from mobile phones.

More than half the traffic to a business’s online store could be originating from mobile. Of course this changes from industry to industry, but the number is only going to get bigger for everyone.

With over half the traffic coming from mobile, businesses need to ask, did half of their design budget, their coding budget, go towards building their mobile experience? These are not second rate citizens you slap on a responsive design and hope it boosts sales a few percentage points.

On average, this 55% of pageviews will end up being almost 50% of revenues (as will be revealed below). 

If businesses don’t build their online stores mobile-first, they can miss out on those revenues. 

Mobile-first means more than a design that fits into the vertical format of a phone screen. Performance is a huge part of the experience. Due to bandwidth and CPU constraints, an ecommerce store that looks slick and performs well on the desktop can look good on mobile but be too slow to load and too sluggish to use.

Google Pagespeed Insights uses a simulated mid-tier mobile phone on a mobile network to measure site performance. It uses the results when deciding how high up to rank sites in their search results. 

A mobile-first approach takes performance on mobile as well as design into the overall UX process.

Stat Number 2 – The Purchase Process

 

46% of consumers complete their entire purchase process
(from research to payment) on mobile.

This statistic, more than any of the others, points to how important mobile is becoming. It is a snowball effect. More powerful phones with bigger displays have made shopping online via a phone more pleasant. The constant growth of mobile traffic has led to new websites always launching mobile capable (if not mobile-first) in order to capture that traffic. And with websites always growing more enjoyable to use on mobile, mobile traffic is capturing more and more of the purchase funnel.

One of the most important ease–of-use changes is the introduction of one-click payments. Digital wallets like Apple Pay and Google Pay, as well as payment service providers like Stripe and Adyen, are creating a new class of customers who are comfortable making online purchases on their mobile phone. One-click payment options remove most of the hurdles to completing payments.

Stat Number 3 – Closing the sale

58% of all multi-device purchases use mobile to close the sale.

There are different ways to interpret this big number. It could be that the digital wallet integration in mobile phones makes completing a purchase on that device the easiest option. It could be that people research purchases on a laptop or desktop, but make the final decision and complete the purchase somewhere more comfortable and conducive to decision making.

There’s probably dozens of scenarios that lead to this result. But they all point to the importance of streamlining the purchase process on your website. It probably means integrating more payment options. It definitely means making sure your website works smoothly across a range of handsets.

On a more technical level, making it easy to share a shopping cart between desktop and mobile experiences will help land more multi-device purchases. This can be by having a very simple sign-up process or being able to capture or send QR codes to access the transaction on another device.

The Kicker Stat – Customers are picky

40% of users will go to the competitor after a bad mobile experience.

That pretty much says it all. More than half your traffic will come via mobile. You can lose almost half of it, or about 25% of your total potential traffic and revenue, if the mobile experience of your website isn’t good enough.

The biggest problem, the one that sends most people away, is websites loading slowly on mobile. Those beautiful hero images that fill your desktop browser window don’t load as fast on a phone. Maybe they do on your iPhone 13 Pro Max. On wifi. But that’s not going to be your mobile audience. It’s also a symptom of building your website desktop-first instead of mobile-first.

How to build mobile-first to maximise mobile revenues

There are no big secrets. It’s a mix of careful design, strategic coding, and backend resources. The two most popular starting points for our clients’ ecommerce websites are WooCommerce and Shopify. They both provide strong options for delivering a mobile experience to your customers.

Shopify is easy to get up and running, and with a careful design and use of resources can be quite performant. But there are limits to what you can tweak. While the ease-of-use makes getting your business online in a reduced time frame possible, you might find the lack of control of the backend keeps you from maximising your customers’ experience. 

WooCommerce is infinitely tweakable. As it is built on the open source WordPress CMS you are in control of the entire stack including the backend. This gives you many more choices in optimising delivery of your website to mobile. It does require more of an initial investment, but many clients feel the control and the power on tap it provides is worth it.

Taking your online business mobile-first

If your current ecommerce website isn’t mobile-first, it is always possible to make the necessary frontend changes to fix that. Making changes to the backend will depend on how your site is being hosted.

If you are setting out on creating a new ecommerce website, then you are in the perfect position to ensure that mobile-first informs your tech choices, your design choices and your overall strategy.

If you have any questions about how your business can make the move to mobile-first or how you should build for mobile-first, drop us an email and we’ll get in touch for a chat.

The big $$$ questions about app development answered

We see the same questions about app development coming up again and again. It’s no surprise. More and more businesses are recognising that they need apps. Developing apps is a complex and opaque process. They’re big ticket items where unscrupulous operators don’t want to share numbers until they can guess how much you have to spend.

We’re going to fix that. By answering your questions. Many of them are of the “how long is a piece of string” variety. We can’t tell you how long a piece of string is, but in our answers we do give some recommendations on how you should be thinking about your string. Or, for this article, how to think about your app and how you’re going to get it built.

Q: How much does app development cost?

Short answer: Under $50,000 for a simple app. Under $150,000 for a basic app. Over $150,000 for a complex app.

Long answer:

You need to be comfortable with spending 5 and 6 figure sums if you want to build a competitive app. If you don’t think you’re going to earn the money back then now might not be the right time to start the process. Maybe start with a basic website.

The cost at each tier comes down to complexity. That complexity is a combination of frontend features, backend/admin features, third party integrations, the amount of business logic that needs to be encoded (after being documented!), and the variety and volume of traffic and transactions your app needs to handle.

A short discussion with us about your app, your market, and the features you want would enable us to tell you which range your app would fall into.

Q: Why does app development cost so much?

Short answer: Details x Time x Expertise

Long answer:

We understand this question. Unless you have worked as a developer on multiple similar projects it can be impossible to look at the screens of an app and see where 5 and 6 figure sums were spent. Hint: a lot doesn’t show up in the user interface.

App development costs what it does for two main reasons: it requires expertise and it takes time. And then there are the details. Building software is all about managing a mind-boggling number of details. It is not unlike building an actual sized house out of Lego bricks. Individually positioning all those little pieces adds up to a lot of time. And you need people who know how all the pieces fit together.

When looking at the cost it helps to remember app development is an investment. You invest in an app to generate revenue. Much as you might buy a machine for a factory, or pay to rent, fit-out and stock a brick and mortar retail store. You expect your big investment to give you more in return.

Of course you’re cost conscious. You spend your money wisely. That is why SoftwareSeni provides full transparency during the entire app development process. You can see the time spent at each stage of app development and even for each feature. Also for all the code that doesn’t touch the screen – the integrations with other services, the code that talks to the database, the code that creates the backend that your business will use.

Q: How long does app development take?

Short answer: At least a couple of months to launch. Then months to polish. Then years to grow.

Long answer:

Our business philosophy combines Lean and Agile methodologies. Under Lean, businesses want to be launching an MVP (Minimal Viable Product) as soon as possible to verify their idea, start gaining users, and start generating revenue.

This is done by implementing features in two-week work blocks called sprints under Agile. You won’t be launching your MVP app after 1 sprint, but 4 isn’t impossible, and 6 is feasible. All depending on your feature set and how far advanced your product conception is, of course.

And once launched, new features continue to be added using two-week sprints, along with addressing any user feedback received along the way.

This process results in lower upfront costs, puts a working Android app or iOS app, or both, in front of your customers sooner, and enables you to start generating revenue sooner.

Q: How big a team do you need for app development?

Short answer: 3-5 depending on the stage of development.

Long answer:

The app stores are filled with apps built by a single developer. So is that all you need?

Maybe? But there is only so much a single developer can do in a week. Or a month. There are only so many facets of app development a single developer can be an expert at. And how many developers are also experts at graphic design or UX or at running user testing?

And the big issue with a single developer – it only takes a single accident, or a single personal crisis, for your app development or app support to grind to a halt. What business wants to take on that risk profile?

A serious app, with a sensible launch schedule, that looks good, that works well and continues to work, requires a team. The size of that team depends on the app, its features, and how the development can be scheduled. But we find that, on average, at any particular stage of the app development process, you need about 3-5 people contributing.

It is a truism of software development that the best way to slow down a project is to throw more people at it. At SoftwareSeni we have launched enough apps, and our teams have collaborated on enough of these apps, that we’re pretty good at putting together the optimal team for creating your app.

Q: Should I develop an app?

Short answer: If you have to ask then you should develop a website first.

Long answer:

An app is a major investment. Are you sure you’re going to get a return on that investment? If you’re not sure, if you don’t have a ready market or an eager customer base, then it will be wiser to test your business idea using a website first.

A modern website, designed to be mobile-first, can approach the user experience of a dedicated native app with a lower upfront investment while providing you access to the entire global marketplace across all devices, not just phones.

Q: Should I develop an Android app or an iPhone/iOS app?

Short answer: Android if you want market reach, iPhone/iOS if you want to charge a premium.

Long answer:

In most of the world Android is the dominant mobile operating system, holding about 75% of the global market. But in some markets, like the US, UK, Canada and Australia, iOS holds more than half of the market.

This difference in market share, and user base, leads to a non-intuitive result. Global non-game app revenue in 2020 was $32.1 billion. Despite its smaller global market share, at about 25%, iOS apps captured $24.7 billion, or 77%, of that revenue.

The decision to develop an Android app or an iPhone app comes down to knowing where your audience is and what your goal is.

For markets like Australia, USA, UK and Canada, where the market is almost evenly split, it’s lucky that there are frameworks like React Native that make developing apps for both platforms financially feasible. But still we would recommend focusing on your iOS app first, because that platform will likely provide most of your revenues.

Q: How long does it take for an app to earn back its development cost? Also: How long does it take for an app to cover its running costs?

Short answer: If you read the first question you already know the answer.

Long answer:

This question is looking at app development backwards. You should not be spending money on developing an app, or purchasing any asset, without forecasting or modeling costs and revenue.

The real question should be: given my forecast revenue and current budget, can I build an app with the planned feature set, keep it running, and market it?

(You don’t want to forget your marketing budget. Expecting enough people to simply stumble across your app is not a path to success.)

If the answer to the real question is no, you don’t have enough money to do all that, then you are left with three options:

  1. Don’t develop an app. Put your money towards another revenue generating project.
  2. Reduce the scope of your app. Will a simpler, less expensive app bring in enough revenue to fund further development?
  3. Build a website instead.  A Web app or a dedicated ecommerce website development is a faster way to reach an even larger market. Websites can have app-quality interaction (at a price). This approach can allow you to invest even less up front and still have a foundation you can extend as revenue grows. With proper planning, converting it to an app when revenue allows can be quite cost effective.

Still have questions about that app you want developed?

Hopefully by answering the big questions about app development we’ve helped you think strategically about getting your app developed.

If you find you have more detailed questions on costs and starting app development then get in contact with us. We’re always up for a chat and we love finding revenue-focused solutions to app creation.

Now, if you feel like you want a little more background on app development before talking to us, we have written a series of short, easy-to-read articles on the process:

A quick guide to Agile for businesses and start-ups
What is product conception and how to do it
How to prototype your app
Business rules and the business logic that drives your app
How the app development process works

Also, here are two articles that will help with your decision making:

Should you build an app or a website?
Fixed price contract vs Agile for app development

Contact us here for any questions you still need answered.

Should you build an app or a website?

Should you build an app or a website

The title might strike you as a dumb question. App vs website? We’re deep in the 2020s. You probably already have a website. But if you’re launching a new product or service or ecommerce play, or you’re finding competition is eating into your revenue, then the question is one you’re already asking yourself – go down the path of, say, ecommerce app development, or down the path of ecommerce website development? 

This article is going to help you make that decision. It’s going to start with a quick tech review, followed by a short discussion of the trade-offs between the two options, then it will jump into the surprise “have your cake and eat it too” twist.  

Let’s start with the tech.

There are only three types of websites

That’s right. Only 3. We’re talking under the hood, not content. Here they are:

Static

Static websites serve visitors pre-generated pages of content. This is how websites worked when the internet was born. It’s had a resurgence in popularity recently due to its speed and security. This tech is best used for sites that don’t change often – blogs, documentation, and brochureware sites.

Dynamic

Dynamic websites serve visitors pages that include content pulled from a database or generated by code. This is called server-side rendering, as the layout and content is assembled by the server delivering the page. It’s more complicated than that, but we’re keeping things simple. 

If a website isn’t static then it’s dynamic. This includes the millions of WordPress sites in existence along with every other site on the internet. The term “dynamic” is now more of an umbrella term, as there are many different ways to build a dynamic website. Web apps represent a relatively recent strategy for building dynamic websites.

Web App

You might have seen this style referred to by a couple of acronyms: “SPA” / “PWA”. “Web app” is simpler. and they all mean a website built to behave like an application. Instead of responding to user interaction by following clicked links to new pages rendered by a web server, web apps pull data off the server and redraw the contents of the current page to display it. This is faster than requesting and loading new pages and creates that “app” feel.

The biggest difference between a web app and web site is web apps are more complex than server-side dynamic websites due to the added complexities of marshalling content on and off the page and the richer interactions they tend to implement.

Twitter is an example of a web app that features the kind of detailed interface and high level of interactivity that used to be only associated with dedicated apps.

Three types of websites

If a website looks like an app and acts like an app, is it an app?

No. While you can build a website with an app-level user experience, when it is visited from a handset it will not have the integrations into the handset operating system a native app will enjoy. It will also lack the look and feel of a native app, placing it visually in a lower tier.

Performance in some areas will also suffer. The biggest one is smooth scrolling. Despite the power of modern handsets, the complexities of displaying rich content in a browser window is still not as smooth and efficient as within a native app. 

Is it easier to build an app or a website?

A modern website built from scratch instead of on top of an existing platform like WordPress or Ghost can be as complicated as an app. When you have things like user authentication, a database for storing data, a way to send emails, an admin interface for tracking metrics and providing customer service features, as well as a professional user interface, you are looking at a lot of code just as you would with an app. With features comes code. There is no avoiding it.

However, there are some tools out there that will make an app from a website. Really, it is just a an app that only displays your website. But users can already access your website on their phone, as we discuss below, so why go this route?

Keeping the killer feature of websites

Websites have one killer feature that apps don’t have – they run everywhere. They run on desktops. They run on phones, no matter who makes them. They can even run on smart TVs. 

When you are deciding between an app and a website you need to understand where your users are and how they are going to interact with you.

It’s a balancing act between audience, features that you need, features that will appeal to the audience, and cost. 

The cost of websites vs apps

A native app with similar functionality to a website is going to cost more than the website. The main reason is simple economics. The number of app developers is much, much smaller than the number of website developers and demand for their services remains strong.

As each of the two major platforms, Android and iOS, have different development environments, releasing your app on both platforms can (roughly) double your costs.

Another cost apps must pay is time. Getting approval for your app from each platform app store takes time, sometimes weeks, with any problems potentially causing long delays. No-one can stop you from launching a website whenever you want.

Each option has its benefits. But you should know there is a strategy that can get you the best of both worlds – the lower cost and lower time to market of a website, and the power and polish of a native app – while spreading out your risk.

Should you build an app or a website?

The app that starts out as a website

This is our favourite strategy for creating a new product or service. It combines the rapid development and deployment of a website, while at the same time it lays the groundwork for the heavy lifting required to create an app.

This strategy is based on React Native. React Native is a spin-off of ReactJS, one of the world’s most popular JavaScript frameworks. If you’ve never heard about React Native you might want to read Everything you need to know about React Native apps – the business side. 

By building a web app using ReactJS it takes much less effort to convert it to a native app using React Native. 

By starting with a web app you can prove the business model of your product or service with a lower investment than going straight to a native app. Once the business model is proven, moving from web app to native app is straightforward. 

How straightforward depends on including this path in your strategy. And why wouldn’t you? Your app will use the same backend as your website. Your UX has been tested and proven. If you built your web app on ReactJS it becomes a matter of changing code that would tell a web browser to draw a form to React Native code that displays a native form on a handset.

And the same React Native code works on Android and iOS. You don’t need a separate team for each platform.

The final answer to the app or website question

So, the final answer to whether you should build an app or a website is you should build the website first. A website designed to be a web app. And if you use ReactJS that website will take you 80-90% of the way towards your app.

When the website shows you have a foothold in the market, it is simply a matter of converting the website into a native app.

If you want to know more about this strategy and how it could work with your business, get in contact with us and we can discuss the details with you.

Turning your idea into action – the how and why of prototyping

Following on from our article on product conception (you might want to read that first), this article is about bridging the next gap in the development process.

That gap is the one between having a solidly documented idea and knowing what to build. This is where prototyping takes place.

When you’re prototyping you want to choose the methods and the tools that let you move the fastest, explore the most alternatives, and make the best decisions in the limited time available.

Read on as we cover the prototyping process.

Who are you prototyping for?

From the Lean Canvas that you would have completed as part of your product conception, you will know who your audience is, and within that audience, who your early adopters are.

Your early adopters are the group you’re prototyping for. And who are they? That’s where personas come in.

A persona represents the ideal member of your audience and is based on data gathered by interviewing your potential customers. It is used to direct high level decision making on product features. Instead of asking “What do we do next?”, personas enable you to ask “What would this customer want us to do next?”, reinforcing a focus on delivering value.

You can read more about personas and how to build them in this article and this article.

Personas are a mix of demographics — age, gender, socio-economic status, etc — and needs. Those needs are the ones your product is being built to meet. How your product fulfils those needs are customer journeys.

Customer journeys – trips through your app

A customer journey can be at its simplest the steps a customer goes through to use a feature of your app. For them, it might be finding their dream holiday. For your app, this might involve performing a search, scrolling through options, and tapping a heart icon.

Customer journeys map transactions, transactions that might be essential or emotionally important to your users, to the functional features of your app. This resonance, this emotional value, that is inherent and intrinsic to the use of your app can become invisible to you as cast it into interface elements and interactions. But it is vital to keep your user personas in focus and the needs that drive them to use your app.

From customer journey to screen flow

Finally the sketching can begin! Screen flows are paths touching multiple screens that users will take to complete their journeys. Each required screen needs to be sketched, considered, and re-sketched. The interface elements — displaying information and providing interaction — need to be selected and arranged. It is an iterative cycle of refinement and feedback. You don’t need to invent a new visual language. The more you follow best practices the faster you can move forward.

Finding best practices for your UX

Dribbble.com is a creative community where top designers from around the world share their work. You can check out current trends and best practices in product design and UX for inspiration right here.

A portion of your customer journey, and thus your screen flows, is going to be product hygiene — the basic features common across apps and expected by users. This includes things like authentication, notifications, etc. We discuss product hygiene in more detail in our article How thinking like Frankenstein will help your MVP.

Don’t be afraid to save time and headspace by finding designs that lay out these standard features and cribbing from them. Definitely don’t waste time “re-imagining” them. Save that for your core features.

Building your screen flows

Don’t jump onto the computer too fast. You can move faster sketching wireframes using pen and paper. It’s called paper prototyping. You can do it with blank paper and a pen or you can sketch in device templates you’ve printed out. But don’t go too far down the path of paper kits and cut-outs, etc. You want to sketch enough that you have stopped scratching your head when you think about how a particular feature will operate.

The bonus is that these paper sketches can be used as part of your initial user testing. Grab anyone unfamiliar with your screen layouts. Ask them to point where they would click, get them to tell you what they would do and what they think would happen. Use these tests to iterate on your sketches — you can redraw on the spot — and improve your design before taking it to the computer.

From paper to screen to interactive

Our tool of choice for building wireframes is Figma. It is a web-based, collaborative design and prototyping tool. The way it enables a fluid conversation between designers, users and programmers makes it an essential part of our recommended process.

Figma provides features that allow you to iterate on your UX. You can quickly throw together wireframes with active elements to create a clickable prototype. You use these along with your test users to refine the screen flows that represent your customer journeys.

At the same time, Figma provides the detailed control your designers need to create the branding and polish that will make new users want to download your app.

The design details — sizes, positions, colours — are all communicated cleanly by Figma from the designers to your developers. So when you’re ready to start coding your app it can happen as quickly as possibly.

Iterate, then iterate, then iterate some more

Figma’s ease of use and shareable prototypes means you can be reaching out for feedback as often as your users can stand it.

You’ve already chosen the key feature set your MVP will be launching with. You’ve got your product hygiene features locked down. The more you can test and troubleshoot and streamline your key features before launch the more you reduce the risk at launch.

Time to start building

You’ll know when your customer journeys are ready for the next step. There will be a shared clarity between you, the designers and the users you introduce to your clickable prototypes.

It’s an exciting point to reach. The end feels so close. You can see how your app will look. You have a taste of how it will function. You have users that want it. All that needs to be done now is the coding.

That’s a big step. Too big for this article. We’ll cover it next when we look at Agile development and the MVP.

Until then, if you have some napkin sketches of an idea you want to turn into a prototype, contact us to have a chat.

If you’re not at that stage yet, but you have a business idea, you might like to check out our article on product conception.

How thinking like Frankenstein will help your MVP

What stage are you at with your MVP? Because the earlier you start thinking more like a mad scientist and less like a FAANG product manager the better your MVP’s chances of success are.

At the napkin sketch stage? Excellent. Wireframing? That’s great. Clickable prototype? Still got time. Coding? You might want to hit pause while you finish this article.

V is for viability

Viable in Minimal Viable Product does not mean that your product works. You’re not going to launch a product that doesn’t work. Viable means it fulfils the business goals you set for it. It is helping to answer the questions about your customers and your market that you created it to test.

The next iteration is also going to be an MVP. So is every iteration that follows as you close in on market fit and profitability.

How fast can you iterate? And how many iterations can you afford? Enough to find that market fit?

You don’t know. No-one ever does. The best you can do is iterate as fast as you can and minimise the cost of each iteration.

Which brings us back to Frankenstein.

Focus on creating, not re-creating

Frankenstein was focused on creating life, not hands or feet. 

You’re creating a product. A new product, never before seen. You don’t want to throw away time and effort re-creating the basic building blocks products are expected to have. 

You want to spend all the resources you can on your unique IP, the features that give life to your product. Everything else is product hygiene.

IP vs product hygiene

You want to minimise your spend on product hygiene. Product hygiene means your product meets user expectations. It has the features they expect. Those features work as they expect. If they need to register, they can register via an email, Google, Facebook, etc. When they go to make a payment, their preferred option is available and it happens quickly and smoothly.

It is a form of visual and functional competency. Professionalism. You can also think of it as table stakes for being competitive in the market. 

A big part of product hygiene is convention. Apps have been around long enough that everyone knows how they work and how they should work. 

When you prototype your MVP you want to split out what parts of it are product hygiene and what parts are secret sauce. 

The secret sauce is where you want to spend your effort and your money. This is your differentiating IP. 

Product hygiene – you want these parts implemented as quickly and cheaply as possible.

Build or buy?

This is where the Frankenstein approach comes in. You won’t be using body parts. You will construct your competition-stomping monster out of SAAS integrations, open source components, and third party libraries. 

Payments is the number one example of adding product hygiene using an SAAS. You could throw money and months at building your own payment system or simply integrate a service like Stripe.

At SoftwareSeni we draw the line between buy and build every day. And every day more features fall on the buy side.

The buy side includes free and open source software (FOSS). It has ‘free’ in its name, but integrating FOSS and maintaining it still costs money. 

Some of the common services we integrate so you don’t overspend on features that provide product hygiene but don’t contribute to your competitive advantage are:

Your moat, the features that make you stand out in the market and give you an edge, will need to be built by you and your team.

Building your moat

In the marketplace moats are built out of code. It can’t be avoided. Just ask Uber. Eleven years after launch, they still haven’t turned a profit, there are numerous competitors, and every local taxi company has a ride hailing app.

That’s a simplistic take, but it has a nugget of truth. If your entire feature set can be built from integrations and libraries you want to revisit your strategy and your idea.

Your moat will be built upon a framework. It might be WordPress, React, Ruby or Laravel. Your choice will depend on your own experience and your inhouse developers’ experience (if you have any). At SoftwareSeni we work across all the major application frameworks.

Your moat will be your entire UX and the business rules behind it. This is where you want to direct as many resources as you can. 

Integrating SAAS and FOSS doesn’t come free, but they represent hundreds of thousands of lines of code you don’t have to pay for or wait to be written. They also represent code you don’t have to maintain. In general, you can estimate that the ongoing maintenance and support of any code written for you will cost about 20% of the development cost per year. It’s just like maintaining machinery in a factory. Pieces start to rust and eventually stop working.  

Bolting together your first MVP, and the next

Hopefully this article has opened your eyes to a different approach to building your MVP. Thinking like Frankenstein, building with off-the-shelf parts whenever you can, will accelerate your path towards your MVP. It will shorten your iteration times and increase the number of iterations you can squeeze out of your budget.

Doing it well requires a wide knowledge of the libraries and services available and how they fit together. This is part of SoftwareSeni’s expertise. Collaborating with you to break down your product idea into the optimum combination of buy and build is a key part of our lean strategy.

If you’re at the sketch stage or ready to code, take a moment to talk to us. We’ll help you get more V into your MVP.

Everything you need to know about React Native apps – the business side

Forget the tech-speak. This React Native overview is for the business savvy, not the tech savvy. You’re here because you need an app if you want to stay competitive. And the app world is unknown territory for you. It’s a different landscape to the web. Different technology. Different, and fewer, service providers.

We know how it is. Choosing to invest in unfamiliar technology is one of those decisions that has a bet-the-farm feel to it. Right now you’re weighing options and worried that you’re about to throw away money, years, and your foothold in the market.

This article will help with your decision making. It’s going to start with a bit of history, so you have sense for the technological landscape. Then it’s going to give an easy-to-understand overview of the concepts behind the technology. Finally, it will cover the advantages of React Native, which are many, and the caveats, which are few, but for some businesses are deal breakers.

The React Native backstory

 

Credit: National Center for Supercomputing Applications/University of Illinois Board of Trustees.

30 years ago(!), in 1990, the first web browser was built. Not many people outside of hardcore geeks saw it. In 1993 the first popular browser was released: NCSA Mosaic, soon to be dethroned by Netscape Navigator. In 1995 Netscape introduced JavaScript to the world.

In the 25 years since, software engineers have been adding capabilities to JavaScript, mastering its potential, and trying to develop strategies to deliver an interactive, application-like user experience from a platform designed to display documents. React, which React Native is built upon, is the latest and currently greatest, manifestation of this.

React came out of Facebook and has been in use since 2011 and open source since 2013. React Native (an extension to React) has been used by Facebook since 2013 and was open sourced in 2015. At almost a decade of use, these are mature technologies powering big name sites and apps and supported by a rich ecosystem of add-ons and enthusiasts.

React was Facebook’s answer to the question – how do you deliver an immersive and responsive user experience inside of a browser?

The same question web developers have been asking each other since 1995. Each time the answer was a little better, giving incremental gains. This time, with React, the answer was revolutionary.

The technology behind React and React Native

At the simplest level, so simple it sounds unimportant, React is very good at telling the browser what exactly on the page needs to be redrawn. The less that needs to be redrawn, the faster the user interface – buttons clicking, timelines scrolling – can respond.

With React, your user can be typing into your search bar at the top of the page, reading the auto-complete suggestions pulled live from the server, while at the same time, at the bottom of the page, a like count updates on a photo. And nothing, except those two elements, a very small part of the overall page, gets redrawn.

It doesn’t sound exciting. But for developers it is. Because it comes along with a method of building an interactive website where React does all the tedious bookkeeping that keeps your site fast, while the developer does all the fun bits related to how it works and how it is structured.

The leap from sites to apps

With React handling the bookkeeping, developers could work at a faster pace and a higher level. That search bar at the top of your page? That could now be a component — a standalone piece of user interface that could be placed anywhere on the page, used anywhere on a site. It could even be open sourced and used anywhere on the internet.

The same with the three step wizard you use to sign up new users. Or a mega menu. Or a video player. Or a chat box.

It occurred to the React team at Facebook that what the code was doing in the browser — creating interface components out of HTML elements like <button> and <textarea> — could be done inside a mobile application. But instead of creating interface components out of HTML elements, it could simply use the native interface components — scrollbars, buttons, sliders, etc.

So React Native was born. At its heart is a virtual machine that runs JavaScript — all the code that covers your business logic, and it translates the calls to display pictures, text and interactive elements into displaying native user interface components.

React Native can be used to run the same code on Android, Android TV, iOS, macOS, tvOS, Web, Windows and the Universal Windows Platform (covering Windows 10, Windows Mobile and Xbox).

Depending on the product, anywhere from 60% to 90% of the code can be re-used from a React-based web app in a Reactive Native mobile app. This is one of the many reasons that at SoftwareSeni we advise clients to test their idea and prove their business case using a React web app – it’s an investment in reusable code in an environment where iteration can happen quickly. Much faster than with a mobile app, where the platform store review process can slow things down.

The React Native advantage

For someone wanting an app for their business, React Native has six major advantages going for it.

Maturity – computer years are even shorter than dog years. 7 years since launch and 5 years open source make React Native an established technology.

Popularity – developers love React and React Native, which means finding developers to build your app is not a problem. Finding good, effective developers — well, that problem never goes away.

Ecosystem – combine maturity with popularity and you get thousands and thousands of open source libraries that implement functions you want and need, dedicated tools and services, as well as experienced partners like SoftwareSeni.

Speed – building a React Native app is faster than developing an app in native code. Multiply that advantage by the number of platforms you’re launching on. And if you’ve started your journey with a React-based web app to prove your business case, the move to a mobile app is even faster. You’ve already done the hard work.

Cost – the speed advantage above should have already clued you in that React Native apps are cheaper than native apps. The availability of developers contributes to that, as does the deep ecosystem of re-usable code. Depending on the app and the team, they can be 2 to 10 times cheaper than native apps across multiple platforms.

Performance – because React Native uses the native components supplied by the device operating system, React Native apps run as silky smooth as a native app. They also get full access to all of the phone’s features — camera, microphone, location, etc.

React Native caveats

Nothing’s perfect. Great as React Native is, it does have a few drawbacks. The biggest one is that it is limited to certain kinds of apps. You wouldn’t make a game in React Native. If your app needs to do large amounts of drawing or manipulating things on the screen, you need to look at building a native app.

If you have an interface feature that React Native does not support you will have to get a custom native component built on each platform you plan to support. It is cheaper than building an entire native app, but it adds complexity and thus cost to the project. Involving SoftwareSeni during the design process can ensure you don’t accidentally end up in this situation.

Finally, a React Native app is only half of the customer experience equation. You cannot forget the backend. No matter what technology you use in your app the backend still needs to be built and that development time and cost is not affected by the app framework.

Take-aways

The take-away from all this is that React Native is a great choice for building an app, if not the best. The apps produced using the technology can stand shoulder-to-shoulder on your customers’ home screens with the likes of other React Native apps from Instagram, Facebook and Netflix.

Throw in the free cross platform features, allowing you to target the top end consumers on iPhones and the mass market on Android devices, and it becomes a no-brainer.

If you’ve been thinking of creating an app for your business, or if your business needs to be an app, get in touch and we can talk about the timeline options for getting your idea to market.