Bespoke Web Development for Startups

Why bespoke web development is the strategic foundation for startup success

In the wonderful world of startups, finding the right web solutions - whether that's a website, customer portal, order management system or something else - can be the difference between success and failure. Granted, that's a bold claim but in this day and age, having the right systems in place to support and promote the business is crucial.

Tailored solutions over template limitations

So, you have your brilliant idea, the investors have bought in, the market is right and you're ready to go! But wait, you realise that in the excitement and chaos of launching your startup you overlooked the gateway to your customers - your website isn't ready! Maybe you have a holding page announcing to the world it's 'coming soon', maybe you had it built in haste and meant to make those last minute tweaks or maybe you completely forgot about it and you don't even have the first draft. It happens. The important thing is...what do you do about it? 

It's a common dilemma and how you choose to act can have significant repercussions - both positive and negative. Do you choose a website builder that promises you a sleek and sophisticated website in no time with no technical knowledge needed? Do you look for a somewhat more hands off solution that offers pre-built templates and cheap labour to do the development? Or, do you take a step back and consider what your website users (both internal and external) really want and expect to see?

There's no universally correct answer but let's take a look at some scenarios that might be suitable for each:

The website builder

Website builders such as Wix, Squarespace and Shopify are designed to help businesses get online quickly with minimal to no technical knowledge required. They provide professionally designed templates, drag and drop editors and managed hosting which make them an attractive option for startups who need a no frills website on a limited budget or timescale. This might be the right option if:

• You're launching a simple brochure based website
• Your primary goal is to establish an online presence quickly
• Your budget is severely limited
• You don't require bespoke functionality
• You're validating a business idea before making a larger investment
• Your website is unlikely to change significantly in the short term
• You don't require integrations with other business systems
• You have no in-house technical expertise and don't want to manage a website yourself

Template based development

Sitting somewhere in between a website builder and fully bespoke web solution, someone with a bit of technical know how can customise an existing theme on the likes of WordPress or Squarespace, incorporating your brand and content. This approach provides more flexibility than a website builder at a considerably cheaper cost than a bespoke solution. This might be the right option if:

• You want a more professional finish than a DIY website builder
• Your requirements are relatively standard
• You need a quicker turnaround than a bespoke project would allow
• You have a low to moderate budget
• Your website requires some customisation but not fully bespoke functionality
• You're happy adapting your requirements to fit an existing framework
• Your long term roadmap doesn't involve highly specialised features
• Your business processes are fairly straightforward and generic
• You don't need your website to integrate with bespoke software

The bespoke advantage

Whilst we didn't explicitly call this out as one of the three, you probably guessed it. Bespoke web development is for all other companies who need something a bit more special. These websites are designed and developed from scratch around your specific objectives, branding, users and future plans. No adapting, no compromise, no limitations.

Requiring the biggest upfront investment, this is certainly not the cheapest approach but it does provide the greatest flexibility, scalability and long term value. This might be the right option if:

• Your website forms a core part of your business model
• You're building a SaaS platform, marketplace or customer portal
• You require bespoke functionality that templates cannot provide
• Your website needs to integrate with other custom software or third party APIs
• You expect your business to grow rapidly
• You're creating a unique customer experience that differentiates you from competitors
• You want complete ownership of your website and codebase
• Performance, security and scalability are business critical
• You're likely to introduce new features
• You want a solution that can evolve alongside your startup without requiring a complete rebuild

Whilst we have focused solely on websites here, these categories apply to all web development including web applications and business systems as well.

Product discovery and requirements gathering

Naturally, startups are keen to get things moving as quickly as possible and that isn't necessarily a bad thing, especially if your website or web application doesn't take front and centre stage of your business. After all, the sooner you start writing the code, the sooner your web project can be delivered, right? Whilst true to an extent, this can be problematic for startups that require something a bit more nuanced, something that doesn't fit the typical molds of builder or template options. If you fall into this category, and are going down the bespoke software route, taking the appropriate amount of time to define the what, how and why of your web development project upfront, is highly encouraged. One of the key reasons why development projects overrun, exceed budget or fail to meet expectations is because the vision wasn't clearly defined from the start.

Defining the vision

So, how's it done? The development team need to sit down with you and your stakeholders to get a thorough understanding of your startup, your products and services, your intended users and the outcomes you want to achieve through the software. This is usually done through stakeholder interviews, documentation reviews and collaborative planning sessions. It's a great opportunity to challenges assumptions, identify potential risks and kick ideas around. The more stakeholders involved and the more feedback received, the bigger the picture the developers can build. They need to ensure the software is fit for purpose from a number of different angles including daily users, management and customers, so understanding how each person is to interact with the software and what they expect to get out it is incredibly useful.

Defining requirements

Once the vision is crystal clear and both parties are aligned, it's time to get into the detail. What features does the web project need in order to achieve the desired outcome, how should it work in order to fit the needs of it's respective user groups? Many startups choose to take the Minimum Viable Product (MVP) approach meaning they start with the core features and functionality only so they have a working system a launch, then build on that going forwards. This is beneficial from both a time and cost perspective, requiring less investment upfront and less time to build than if it were the full solution with all bells and whistles included.

Choosing the technical direction

Now for the technical part. The developers, in conjunction with your team, will then decide on how to architect your web solution. Choosing frameworks, languages and all the other boring stuff is extremely important, the developers need to make sure that the architecture of the solution reflect the requirements and will be considering the capabilities of a range of technologies for things like integrations, scalability and the user experience.

Why discovery is so important

If it's not already obvious, the discovery phase of any web development project is critically important and maybe even more so when it's for a startup. Skipping this process or not dedicating enough time to ensure it is done thoroughly will not save you time in the long run, rather, you'll find yourself doing it retrospectively when you realise the software is not shaping up to do what you expected it to do. 

Conversely, dedicating the time and effort upfront to ensure the discovery phase is comprehensive enough that everyone understands what needs to be done, how it needs to be done and when it needs to be done, you'll find the experience to be much more pleasant with no ambiguity, no scope creep and no expensive redesigns.

These are the outputs you can expect to get from a well rounded discovery phase:

• Clearly defined business objectives
• User personas and customer journeys
• A prioritised feature list or Minimum Viable Product (MVP) if relevant
• Functional and technical requirements
• Wireframes or early concepts where appropriate
• Recommended technology stack and software architecture
• An indicative project roadmap and delivery plan

These are the outputs you can expect to get from a half baked discovery phase:

• A vague idea of what the solution should look like

Which would you prefer?

MVP - First development philosophy for startups

There is definitely some truth to the stereotype of startups being frantic, chaotic and wanting everything to be done yesterday. After all, when you've got a great idea, of course you want to include every single feature you've ever imagined before launching - who wouldn't? However, think about it from another perspective: the longer you spend designing and developing your product, the longer you are delaying that all important, real customer feedback. Aside from costs and resource requirements, this is one of the main reasons why startups choose to launch with an MVP rather than the full and final product.

An MVP is NOT a proof of concept

A common misconception in many businesses today is that an MVP is the same as a proof of concept or a prototype - it isn't.

Prototypes and proof of concepts are used to demonstrate ideas. They are not necessarily meant to be functional, rather, you might use them to secure investment, get early feedback or explore prospective user journeys. 

An MVP is an actual, functional product built using production ready technology and designed to be used by real customers and/or employees. MVPs tend to include only core functionality - the minimum required to be classed as an actual functional product - with the view to further developing them into a fully finished platform with all features and functionality sometime in the future.

Only the essentials

Whilst this sounds easy in principle, deciding what not to build can actually be very difficult. Regardless of what the feature is, there will always be the lingering thought that not having it now, will inevitably put some people off the product. To try and make this a bit more straightforward, you can ask yourself one simple question: Does this need to exist in order for us to launch? If the answer is no, put it on the roadmap for future development. Remember, by forfeiting these features temporarily, you're allowing yourself to get real customer feedback quicker and real feedback is of unmatched value when improving and enhancing your web product.

Build for today. Architect for tomorrow.

We've told you what an MVP is, now let us tell you what it isn't. It isn't cutting corners. 

Despite the fact the feature set and scope is intentionally limited, the underlying architecture needs to be designed to ensure it is ready for the additional, full set of features to be added at a later date. This means, the technical foundation should be built with the full picture in mind and with the technology and methodology to support it. Integrations, additional functionality and users should be a breeze to add in the future because the foundations are already there for them.

Incorporate feedback as quickly as you receive it

As we have already alluded to, real customer feedback is priceless. Having your target users tell you the good, the bad and the ugly from their perspective as a customer, provides invaluable insights into what is working, what isn't and where improvements can be made.

This feedback should be top of the priority list to act on and you may find, it differs to what you expect. From your view, as the founder or senior manager of the startup, you may be panicking because the MVP you have doesn't include x, y or z functionality. In reality, your customer might focus on how you can improve the existing user journey, reduce the steps involved in a certain process or explain something a bit better rather than focusing on what's not yet there.

UX design, wireframes and prototypes

A great idea doesn't guarantee startup success. If your intended target audience can't quickly understand what your product is, how it works and how it will benefit them they will quite simply move on. Plenty more fish in the proverbial sea for them to explore instead. That is why investing time and effort into UX (user experience) design prior to development starting, is so very important.

The role of design thinking

Design thinking is exactly as it sounds - thinking from a design perspective at every opportunity. This thinking puts the user at the heart of every decision, shaping the design of the software to ensure it incorporates what your users actually want. 

For startups, this approach helps to avoid building features and functionality that users are not going to benefit from in some way and instead, focus on perfecting those that they do need and want. The resulting software is much more likely to provide a positive user experience if user journeys, pain points and expected behaviours are considered and built in from the start. Providing a great user experience also offers additional benefits through an increase in user adoption and long term customer loyalty - if they don't have a reason to move, they won't!

The importance of wireframes in translating business requirements

Wireframes are a great addition to any development project and can act as a sort of blueprint for the solution. Whilst they don't typically go into detail on the proposed technicalities, they do provide a visual depiction of the finished product showing where information, navigation and functionality will appear on each page. And let's be honest, investors and prospective users are going to be much more interested in this, than they are in technical infrastructure behind it.

Wireframes are not generally the same as finished designs, they are intentionally simple and allow designers, developers and stakeholders to discuss layout, workflows and functionality early in the project without being bogged down in granular detail. Having a visual starting point can help everyone build a picture of what the final product will look like which can be difficult to do through specifications that rely on words alone.

Interactive prototypes for early engagement

When wireframes aren't enough - you can look to take the next step and turn them into interactive prototypes which should closely simulate the behaviour of your finished product. At this stage, stakeholders can usually click through screens, complete basic activities and experience the overall look, feel and flow of the web software without it actually existing.

Prototypes are useful for many reasons but even more so for startups because they provide stakeholders with palpable confirmation that the project is headed in the right direction, they give investors something tangible to experience during any funding discussions and they allow target users to test and feedback on the product before development even begins. It is much cheaper to act upon feedback at this stage than when the full product has been developed and delivered!

How UX design decisions impact conversion rates

In short - positively. All design decisions made before the development gets underway can have a significant impact on how successful the finished web software is. Feedback can help to create clear navigation, intuitive workflows, well positioned calls to action and straight forward onboarding - all of which contribute to a great user experience.

Regardless of whether your intention is to encourage early registrations, increase subscriptions, generate enquiries or push online sales, removing any sort of obstacles from the user journey before it becomes a problem makes it much easier for your visitors to take the desired action.

All of this to say, for startups, investing in UX, wireframing and prototypes is usually very much worth the investment.

Choosing the tech stack

Some founders may concern themselves with this, some won't. Regardless of which category you fall into, it's perhaps useful to understand the thinking behind the technology choices made by the development team. 

For founders that do care about the technology being used, this could be for a myriad of different reasons. They may already have some experience with certain programming languages, frameworks or cloud platforms, allowing them to contribute to technical discussions and making it easy for them to troubleshoot and manage the software as needed. They may also have existing systems they want to integrate with the new software so the technologies used need to be compatible. They could have internal technical resources who have a specific skill set or even investor requirements that influence the technologies being used.

For founders who have no interest in the technology being used aside from it being suitable for the solution, their focus is going to be on the outcomes it can achieve. Does it provide scalability? Is it reliable? Is it secure? Is it maintainable? Any good development team will be able to recommend appropriate technologies based on what's important to your project.

The developer review process

Developers should not recommend technologies just because they have favourites. All technologies have their own pro's and con's and the requirements of the project should be the main driver of such decisions. Common factors developers will consider when assessing which technology stack to use are as follows:

1. The complexity of the requirements
2. Expected user numbers
3. Future growth plans to the extent that is known
4. Performance requirements
5. Integration requirements
6. Time to market
7. Maintenance expectations
8. Any plans to retire or replace the technology
9. The size and quality of the developer community
10. Security requirements

Some startups may simply want the technology that will allow them to get to market quickest. Others may have already secured investment with a long list of engaged prospects meaning they need technology that can accommodate hundreds of thousands of users from day one...needless to say the approaches here would be very different.

Front and backend frameworks

Let's take a look at some popular front and backend frameworks:

Frontend

Angular: A comprehensive and popular framework, Angular provides a structured approach to building large, complex and feature rich web projects. It is a great all rounder and can be used for building intricate SaaS platforms, complex enterprise systems and products that are meant to evolve over a long period of time.

React: One of the most widely used frontend libraries, React is well suited to startups looking to build highly interactive applications. It has an extensive ecosystem, reusable components and wide community support all of which make it a great candidate for software that is meant to grow at a rapid rate.

Vue: Regularly praised for it's simplicity, Vue promotes rapid development whilst remaining highly capable. This makes it a popular choice for startups building applications that need to be delivered quickly and aren't too complex - customer portals, dashboards and internal software are a few examples.

Backend

.NET: Part of the Microsoft family, you already know it's going to be good! This mature and highly versatile backend framework can be used to build everything from websites and web applications to APIs, enterprise software and cloud based platforms. A fantastic choice for startups developing products that need a solid technical foundation with room to grow.

Ruby on Rails: Not so popular these days, but still with lots to offer - Ruby on Rails is good for startups looking to build and launch quickly. It's mature conventions and extensive libraries allow developers to deliver functionality quickly whilst being able to maintain clean and structured code.

Python: Widely regarded as the easiest programming language to learn, Python is a well established technology known for it's readability and huge ecosystem of libraries. It's a solid choice for startups who want to incorporate advanced tooling into their system including AI, machine learning, automation and complex data processing.

Content Management System (CMS) integration

Now some good news - not every part of your website, application or software system needs to be hard coded. Marketing pages, blogs, case studies, help centers and general information are all examples of content that benefits from being managed through a CMS.

If you're a SaaS startup, you could give your marketing guys access to a CMS so they can publish blog articles, create landing pages for advertising campaigns and update pricing without needing to wait for a developer. If you're in the ecommerce space, you might want to manage your buying guides, promotional pages and product information and advice through a CMS. There are use cases for using a CMS for most industries - if you want to keep on top of content without the need for technical resource, it's probably a fit.

Let's take a look at some popular CMS systems and why you might want to use them in your startup:

What on earth is a headless CMS?

It's not as macabre as it sounds, quite the opposite in fact. In essence, headless CMS completely separate the content management aspect from the presentation layer. This means developers can build a fully bespoke frontend whilst the content editors have free reign to update text, images and all other manner of content without it having any impact on the design or functionality of the system. You could liken it to changing the contents in the boot of your car - camping gear, shopping, you dog - regardless of what's in there, the car itself doesn't need to be changed to accommodate it.

API's, integrations and third party services

It's somewhat of a rarity for startups to build or utilise software that doesn't need to communicate with other software. Most systems need to interact with payment providers, email services, CRMs, accounting platforms and countless other systems. There are different ways to make this communication happen but the most popular by far is through Application Programming Interfaces or APIs, they facilitate the exchange of data between systems and allow data to be pushed and pulled automatically.

The custom API enabler

Many applications and third party services already have ready built APIs that allow other software to connect to them - these are known as off-the-shelf APIs and are offered by companies such as Stripe, Xero, Shopify, Salesforce and thousands of other software providers. Off-the-shelf APIs make it relatively straightforward to integrate common functionality including payment processing, accounting, ecommerce, mapping and email delivery without having having to build this connectivity mechanism from scratch. They are ideal for startups, offering a non complex, quick way for them to tap in to additional services.

Bespoke APIs have a different use case altogether and are relevant when a company needs to expose it's own data and functionality to allow other software or services to connect to it whether they be external or internal. Externally, a bespoke API might allow customers to retrieve their order history from your platform, suppliers to submit inventory updates automatically or give partners access to your booking availability. Internally, a custom API could be used to allow your mobile app, customer portal and administration dashboard to retrieve information from the same central API meaning every system is using the same, consistent, up to date data.

To summarise, off-the-shelf APIs allow you to connect to someone else's software, accessing only the data they have permitted you to whereas bespoke APIs allow other applications (whether they're your own, your customers or your partners) to connect to yours.

Integration ready architecture

Although uncommon, some startups haven't even thought about integrations. Perhaps you don't foresee your software needing to integrate with anything or maybe you anticipate only needing to connect to a payment platform or email provider which doesn't require any specialist infrastructure. If you can be absolutely sure of that now and well into the future, then you probably don't need to opt for an integration ready design for your web project's architecture.

However, if there's even the slightest chance you might encounter a situation whereby your system needs to connect to other applications to exchange data then you really should be making sure is is reflected in the design of your software. You'll thank your past self!

Integration ready doesn't mean building the integrations themselves from day one but rather, deciding on a technology stack and architecture that makes future integrations straight forward. Using well defined APIs, modular components and clear separation between different parts of your system will ensure new integrations can be introduced with minimal disruption allowing you to jump on new opportunities to please your customers as soon as they present themselves.

The best time to prepare, is before you actually need to!

Security, testing and quality assurance (QA)

Going back to the stereotype of startups and their founders wanting everything ready yesterday, another problem that can arise from this is the security and quality of the web project. It may be tempting to rush over these critical aspects so you can just get your software deployed already but unless you're happy to turn your early adopters off with a buggy, unreliable, vulnerability laden excuse of a software system then it's not worth cutting corners.

Now, whilst that might be an unkind way to describe the software, it really could end up being accurate. It doesn't matter how much testing is done through the iterative development cycle, it is still absolutely critical to test the software as a whole and from different user personas. Your first users are arguably your most valuable and if their first experience with the software is one of more crashes than the TT, slow performance, broken functionality or security concerns, why would they bother wasting their time any further?

Security first

Security is not an add-on, nor should it be an afterthought. The architecture and design of the software should be influenced by security, considering everything from how users authenticate to how data is stored and transmitted through the software.

Modern web projects - specifically - web applications, generally incorporate multiple layers of security including encrypted communications (HTTPS), secure password hashing, role based access, multi factor authentication, input validation, protection against SQL injection, secure session management and regular dependency updates. This should be the minimum and more security protocols are encouraged at every opportunity. Making sure these measures are incorporated into the application from the start is much more beneficial (and convenient) than trying to retrospectively add them after launch.

Testing, testing, Houston...do you copy?

We have already touched on testing and the benefits of an iterative approach (where testing is completed during development after individual components are built). This generally falls under 'unit testing' because it refers to testing individual parts of the software rather than the whole solution. However, there are other types of testing that need to take place, usually prior to deployment of the solution to ensure all aspects of the software have been fully tested and approved both individually and collectively.

Integration testing

Whilst this can be tested during the development phase, comprehensive integration testing is usually performed once multiple components have been brought together into a working solution. The aim is to verify that different parts of the system interact with each other in the manner intended and might include communication between the front and backend, databases, authentication services, payment gateways and any other third party integrations the software relies upon.

Performance testing

Again, performance testing can be carried out at a component level but should also be carried out on the whole solution prior to deployment. This involves measuring how the software performs under realistic and extreme scenarios and can be undertaken through simulating hundreds or thousands of concurrent users observing page load times, server resource utilisation and database anomalies. This is vital for startups who expect their product to be adopted by lots of users quickly.

User acceptance testing (UAT)

A 'test' from the people who will actually be using the software - the ultimate approves. UAT gives stakeholders and representative users the opportunity to test the software in real world scenarios before it goes live. This is not about the technical correctness of the software, rather, it focuses on whether the software meets the business requirements and outcomes it was intended to. It is incredibly important in identifying non technical issues such as navigation, workflow issues and useability which all have a tendency to be overlooked when testing purely from a technical perspective.

End-to-end testing

And finally, end-to-end testing validates complete user journeys from start to finish confirming every part of the software works together as expected. In ecommerce, this might involve creating an account, browsing products, adding items to a basket, placing an order, processing payment, receiving confirmation and confirming the order is visible in the test customers account. 

Quality assurance (QA)

Whilst testing is a part of QA, there's a lot more to it than that - QA is about embedding and reiterating quality throughout the whole development process through various means.

One of those means is code reviews. Before new code is merged into the main web project, it is reviewed by another developer (or a group of them) to identify potential bugs, security vulnerabilities, performance issues and opportunities for improvement. A fresh pair of eyes is better placed to spot potential issues over the original developer who might be a bit 'code dead' after looking at their own code for so long.

QA also includes more abstract concepts including coding standards and best practices. These will differ from company to company but providing all developers within that company follow the same consistent conventions for naming, structure and documentation, the software should be easy to understand, maintain and extend.

Another important aspect of QA is requirements validation. This goes hand in hand with an iterative approach and means individual features are checked against the original business requirements to confirm it solves the problem (where applicable) and behaves as intended before it is signed off.

Documentation is another important part of QA and an area where many development teams fall down. Well documented code, APIs and system architecture is necessary to maintain the software, troubleshoot when issues arise and onboard new developers in future should that need to happen. 

Ultimately, quality assurance is all about creating confidence for those involved or affected by the software. Confidence that new features aren't going to break existing infrastructure, confidence in the security of the system and confidence the software can continue to perform as the business grows and changes. 

Compliance considerations

If there's one word that can send shivers up the spine of even the most ambitious of founders it's that dreaded C word. Compliance.

Not every startup is going to operate in heavily regulated sectors such as healthcare, finance or education but even so, there are legal obligations that all companies must comply with and startups don't get a pass just because they're brand new to the game. 

Starting with GDPR and The Data Protection Act 2018, startups who are collecting and/or processing personal data must understand what this legislation contains and ensure their processes, workflows and indeed web software is set up in a way that ensures compliance to it. This might mean including features such as user consent management, data retention policies, audit logging and automatic deletion of data after a certain period of time.

For startups that do operate in heavily regulated industries, they must usually go further. Sometime, MUCH further.

There is one way and one way only that companies can avoid having to adhere to these compliance regulations and that is: don't start a business in any of these industries in the first place!

To finish

Successful web development depends on strong foundations. Strong foundations depend on careful and comprehensive planning, strategic design and expert engineering. Taking the time to get all of these fundamentals right will set your startup up for success now and well into the future.

See also