Broken. A story of Online Development – Part 4

This 4-part series provides a useful primer on how to approach technology and manage its integration into a business, with the aim of avoiding unexpected costs and issues.

Strategy Tips

Finally, some rule of thumb strategy tips that may help discussion. 

  1. Get specific about the requirements for your project. Have an official process for modifying the scope of a project. Try and not do this, while developers are building it. Specify the delivery milestones. Minimise meetings and feedback in the middle of the work. Make sure the documentation includes the testing plan and methodology. Every platform and system you build will have maintenance tasks specified in the requirements. 
  2. Prioritise actions that focus on revenue acquisition and preservation through customer experience.  
  3. Invest in prototyping and user experience (UX) architecture, to test things out before development.
  4. Make sure developers have coding standards to work to. Comment and document everything.
  5. Consider tech debt separately from project management. Time, Quality, Cost, Pick two has been the project mantra. Time mostly because of the perceived first mover advantage. Cost due to having to pay business costs until the project produces revenue. However neglecting the quality can produce debt time bombs and increase the time and cost beyond any initial savings.
  6. Over time find your greatest sources of tech debt and nail them down. Use your internal team and customer feedback loop. Have a process in place for monitoring all aspects of your business technology, with an emphasis on prioritising the tech debt backlog. Align tech debt to your businesses risk planning.
  7. Reprioritise investments in legacy systems, infrastructure and skill sets. Be flexible and use a requirements process to transition as business needs change. This often means abandoning obsolete and dysfunctional systems and processes. It means changes in customers, staff, supply chain and moving to new technology.
  8. Staged releases and minimum viable products (MVPs) may allow for customer feedback loops to form a part of product development.
  9. Keep a lid on Shadow IT where frustrated and impatient team members are tempted to deploy their own solutions outside a coherent architecture. Unmanaged tools have both security issues, create duplication in process and also break data integrity.
  10. When reading tech articles to choose platforms, also read the comments section from readers. This is where you will find some of the ‘gotchas’ with any particular platform.
  11. When using any technology from a third party (which is just about everything), familiarise yourself with the service level agreement (SLA) and how to access support. What is the cost of that support? How quickly will it be offered? What are the cost tiers? Realise support won’t generally cover anything you have customised, so who is supporting that? Is it all documented? When you use a hosted platform you might get a lot of functionality in the deal though you are putting your hands in the way that company works and its development roadmap. 
  12. Will you have to add in a lot of plugins to do what you want? Is the cost of those ongoing or a one off payment?
  13. How easy is it to write custom code or customise the system? Can you build the navigation the way you want it?
  14. Is the platform you’re using geared towards your country? Particularly in regard to payment platforms and their cost? Can you display local taxes in a way that your customers expect them? Can you calculate shipping costs properly? Does the platform allow you to comply with the EU’s GDPR (General Data Protection Regulation) or CCPA (California Consumer Privacy Act) or others, if that is a factor?
  15. How does the platform protect you from scammers in the service level agreement?
  16. Pick hosting suitable for the platform tools you want to use. Virtualise where possible and use content delivery networks to ensure delivery is as near to the customer as possible. Configuration such as email needs to be considered. Don’t send bulk email on shared hosting unless you want your site shut down by the hosting provider.
  17. Sometimes platforms contain a lot of tech debt themselves and this may have a huge impact on the speed and viability of a site. Caching, compressing and minification plugins can have a positive effect on this, though this is also a function of picking a platform category suitable for your project. Legacy code can also be a security leak and a lot of sites get hacked for this reason.
  18. Consider setting up a staging environment to test changes before pushing to a live environment.
  19. If the majority of your usage is on mobile devices, particularly phones, then prioritise the experience on those devices.
  20. Making improvements on a legacy system to extend it can massively increase the cost when a new system is required.
  21. Hire the right skills. Parallel development where there are different teams (say a back end app team and front end web team) can cause issues at the handover point of the user experience.
  22. Make sure somebody is responsible for each thing. Including a great technical lead.
  23. Parts of the code may become inefficient over time and should be refactored to support future requirements. The longer refactoring is delayed, and the more code is added, the bigger the debt.
  24. Are there ongoing costs to continually promote content? Is the reach and frequency of a particular platform or advertising medium declining? Have you considered the amount of content that may have to be produced to keep up a content driven strategy? Have you factored in writing any copy? Can you structure your product content the way your business does? Can you add custom fields? 
  25. What does the theme look like? Is there great photography that you will have to replace with your own? How is that going to make it look? What is the cost? Will stock imagery make your brand look ‘hokey’. What about choosing that theme, or editing it?
  26. What is the platform or payment provider’s policy on transferring your funds to you? Are they going to be held up? Can you do reverse charges? What percentage of cost is there with each transaction? Does the platform still keep a transaction fee if a sale is refunded? Can you operate multiple currencies or popular credit cards? 
  27. How do you follow up on abandoned shopping carts?
  28. Are you able to sell digital products and what are the file size specifications? 
  29. Do you need point of sale integration?
  30. How are you managing site membership?
  31. Where is your data sitting and on whose servers? Is this compliant with your legal responsibilities?
  32. What API (Application Programming Interface) tools are you using and what is the cost of the transfer of data from these tools? 
  33. How easy is it for customers to end up with duplicate accounts due to changed or mistyped email addresses?
  34. Compile your code with the latest compatible libraries and SDKs (Software Development Kits). Do you really need every one of those libraries? Build and test reusable components.
  35. Have you considered adding analytics and reporting to your development? What reporting tools exist in your chosen platform? Are they in the tier you have subscribed to or cost extra? Do you know how you are going to bring together all the various data into a cohesive set of reports?
  36. Are you testing your site’s speed? Does the site comply with Google’s Core Vitals? Core Web Vitals are a set of targets relating to the speed, responsiveness and visual stability of a website; sites that meet them can receive preferential treatment in Google search results.

Broken. A story of Online Development – Part 3

This 4-part series provides a useful primer on how to approach technology and manage its integration into a business, with the aim of avoiding unexpected costs and issues.


By this stage, you should have a blueprint for your project that outlines the Business, Functional and Technical Requirements. With this in hand, you can now begin to match the right platform tools to your requirements to start building the project. 

Choosing a supplier before you have a clear idea of what you need can be like gambling with the odds against you. However, if you do your due diligence and research, you could join the ranks of the 13-20% who take that path.

At this stage, you’ll probably know roughly the kind of software development vehicle you need to get to your destination, allowing you to make more informed decisions and keep the journey in your hands.

Platform Categories

Here I categorise technology platforms in order to facilitate discussion about which approach(es) is/are needed for projects and platforms.

Within each category there may be a variety of competing products. For example, in the area of Content Systems there may be multiple solutions available.

When working with consultants or potential vendors, you can use the questions from your requirements to assess how well their platform matches your project. Utilise your research and knowledge to determine if it is the right fit.

This categorisation also provides a structure to evaluate existing platforms used within an organisation and identify areas for improvement. 

They are:

  • Tier One – Hosted Platforms
  • Tier Two – Wordpress
  • Tier Three – Database and Middleware
  • Tier Four – Prototype, Low Code and No Code Platforms
  • Tier Five – Static Generation and Code Frameworks
  • Tier Six – Apps
  • Tier Seven – Insight, Data and Analytics Projects
  • Tier Eight – Enterprise Systems

Tier One – Hosted Platforms

When these platforms first emerged, they promised that anyone could easily create their own projects without needing a developer.

As they have added more sophisticated elements to keep up with their competitors, however, many of them have attracted specialised developers to take advantage of the new features.

I think the range spans from using a Facebook Page, a hosted builder (such as SquareSpace [2003],  Wix [2006] or Weebly [2006]) or more sophisticated shopping platforms such as Shopify (2006) or BigCommerce (2009). There are others, though that’s the basic idea. 

Many platforms now offer a commerce component as part of their core offering. Shopify makes it easy to integrate an online shop into your Facebook page for example. 

When you use one of these platforms, you are subject to the platform company’s development roadmap and any changes they make. This must be taken into account when assessing your risk and tech debt strategy.

Tier Two – Wordpress

WordPress (2003) stands alone in its niche, combining an interface with middleware and a database like Tier Three, as well as offering a hosted option. It is easy to set up for many integration developers, who can add a template, plugins and have a website running in no time. Furthermore, it is completely customisable depending on the scope and skill of the developer.

You might not want to build your new product platform directly on WordPress, but a savvy developer could still use it for many applications, or even host other apps on the same server. Additionally, WordPress has the popular WooCommerce plugin for setting up an ecommerce store.

WordPress makes it easy to get a website up and running quickly with its selection of plugins, themes, and page builders. However, the abundance of code that comes with this setup can be prone to bugs as much of it is being rewritten from PHP to  JavaScript.

Tier Three – Database and Middleware 

This tier of the software stack consists of databases and middleware, such as most Content Management Systems (CMS). A CMS typically features a web interface, middleware to communicate with a database, and the database itself. 

WordPress and other content management systems have evolved from their roots as blogging platforms, where content was the primary means of engaging with an audience. Nowadays, however, utility value is often the focus when selecting a CMS; users are more likely to choose a system that enables them to achieve something specific. This is particularly true for businesses where content is a core part of their offering, or when opting for a headless CMS with no front-end templating.

Some example products may be Drupal (2001), Joomla (2005),  Expression Engine (2005), Craft (2011), Umbraco (2005) and Kentico (2006). HubSpot (2005) is in this space as well, linking their CRM solution with content management, although that could really be considered part of a hosted solution.      

Many of these platforms were originally created with a focus on content, and the introduction of eCommerce functionality has been an afterthought. As such, they are beginning to show signs of ageing technology, with increasing levels of technical debt.

Tier Four – Prototype, Low Code and No Code Platforms

Low code and no code platforms are aimed at ‘solopreneurs’. They allow for rapid prototyping for startups. This can be necessary when despite having tight requirements documentation, you need to also try things out and iterate. They may increase collaboration between business teams and development teams. These prototypes can be developed previously in visual products such as Figma, Axure, Sketch or InVision. An actual working prototype though, may allow greater clarity. They allow a focus on the architecture and outcome rather than on the technology.

One of the best examples is Bubble.io

Low code and no code is not a great name as it makes a lot of people think that nobody had to code these in the first place, and aren’t currently coding up new features in the background. They feel like the developer version of the hosted platform, and a natural successor to services such as CodePen

They can also be a way for developers to increase productivity by automating tedious work whilst allowing them to also write code modules.

Alongside this, connection tools such as Zapier allow integration of platform tools, code, low code and other applications to work together.    

Tier Five – Static Generation and Code Frameworks

This is where we start straying into hardcore developer territory. These are projects where a developer has an IDE (Integrated Development Environment) such as Visual Studio Code and a development environment on their machine. Usually a Mac because it’s Linux based. That’s why you see all those developers rocking MacBook Air. 

Usually a project will have a repository on BitBucket or GitHUB, with a pipeline setup to push changes to the ‘repo’ and with automation to the ‘Staging’ or ‘Live’ site. Frameworks such as Node.js (2009), Golang (2009), React (2013), Vue (2014) , Grunt (2016), Gulp (2013), Docker (2013) and other libraries form part of the project that is compiled and delivered to the web server. Sure we can also yell out, PHP (1995), .net (2002) though in heavy usage, this isn’t the most modern set of tools anymore.   

This is where fully customised developments get built. The environment allows full control over the development, and the ability to control the source code, working in a team via the repository. This allows a company full ownership and control over the source code with the ability to put in place processes to minimise tech debt.     

Many of the hosted solutions would have this kind of team and development structure sitting behind them. 

Tier Six – Apps

Apps are built where there is some ongoing ‘utility value’. Something that you can do with the app on an ongoing basis in the context of a mobile use case. You can use it again and again, in the best case on a daily basis. 

A good example is Spotify (2011). If you are listening to music on your phone or tablet, you can continue when you get home in the desktop app. There is also a web version for all devices. There is deep-linking from web to app where the app can be triggered to open and continue on with a track you have been listening to. 

A plane booking app is a lesser example where the app is useful, though you might not use it every day unless you are an extreme traveller. 

One of the biggest tech debt areas on apps is the integration of Google Analytics tools which can be vital for measuring conversions and interactions. Platforms such as Unity (2005), Sencha (2010), Xamarin (2012), Firebase (2011) and Flutter (2018), exist for developing apps. In this space many hosted app development tools have arisen and the same caveats apply to those, as hosted web development platforms. 

Tier Seven – Insight, Data and Analytics Projects

The concept of bringing all your data together and presenting end-to-end insight is becoming a big deal. Not the dashboards we have seen for years with bar charts, pie charts and funnels only. Those have generally been coming from 3 sources. Advertising, Sales Data and Analytics. The best solutions bring these together, merging the data and allowing for ROI measurement, insight and service design.

Advertising data from agencies can include Google Marketing Platform (2018), Adobe Experience Cloud (2012) or from simpler sources such as Google Ads (2000), UTMs, Facebook (2004) and others. Customer relationship and sales data can come from products such as Salesforce (1999) and HubSpot (2005). Interaction and user data can come from Google Analytics (2005).

Data can be integrated with a Customer Data Platform such as Tealium IQ (2011), or combined in a cloud database such as BigQuery (2011). 

Visualisations could then be provided in a number of business intelligence tools such as DataStudio (2016), Tableau (2005), Power BI (2011), Metabase (2014) or customised. 

Tier Eight – Enterprise Systems

Although a corporate entity may have a customer-facing website with all that that entails, the service is generally delivered by a portal that needs an enterprise level framework for security (e.g. financial, online banking, customer data platforms, military). 

Even in this space though, the tools may have been around a long time. For example if you were working with a legacy system it might be Java based and use J2EE an enterprise framework. This was first released in 1999, 23 years ago. COBOL code still drives a lot of old servers, particularly government. COBOL was released in 1959, 63 years ago. 

There are big moves towards Tier Five frameworks for enterprise and the internet is constantly evolving in this space. There is a lot of patched code out there.  

The Future

What’s the future? This analysis shows that there is a lot of legacy code and platforms out there. That means a lot of opportunity, though also a lot of tech debt for companies to get into, and hold back innovation.  

Augmented Reality, Artificial Intelligence, Machine Learning, Web 3.0. A lot of expansion is happening.

In our next and final article in this series I’ll just list some strategy tips to bring it all together. 

Go to Part 4



Broken. A Story of Online Development – Part 2

This 4-part series provides a useful primer on how to approach technology and manage its integration into a business, with the aim of avoiding unexpected costs and issues.

Consumption and Tech Debt


Any development project you initiate will have to be ‘consumed’ – meaning that you’ll need to be able to incorporate the results of any project into your organisation. 

You and your team need to be able to plan, implement, use, and evaluate the effectiveness of the project. Doing so will ensure that the investment of time and resources is worth it in terms of the return on investment.

Are you and your team prepared to embark on this project? Do you have the support, approval, and eagerness of all the necessary people? Even if it’s just yourself; have you thought through the desired outcomes?

Integrating the development project and the delivered site, app or system into a business requires anticipating scenarios that may include an influx of customers, potential impacts on customer service, or the time needed to manage the new system. Having contingency plans in place can help ensure successful integration.

Research from Gartner has consistently shown that a large majority of IT projects fail, with 75% failing in 2017, 87% of data science projects never making it into production in 2019, and only 20% of analytic insights delivering business outcomes by 2022.

Some initial considerations

  1. Outcome: Start with the desired outcome: What business objectives are you trying to achieve?
  2. Technical: Consider technical expertise: Do you have the necessary knowledge and resources to build the product, or do you need to outsource?
  3. Budget: Determine budget requirements: Based on your scope of work, how much money will be needed? Get multiple quotes for comparison. If you are in a startup, consider raising capital and seeking advice from experts.
  4. Functional: Identify all functional components: What steps must be taken in order to reach your desired outcome?
  5. Evaluate: Evaluate user experience: Is the product easy to use? Are there any potential issues that could arise during use?
  6. Future: Think about scalability: How easy is it to build upon this version of the product in the future?

Your development plan should take into account the return on investment from a business perspective, as well as architecture, design, development, code management, testing, documentation, infrastructure, people and process requirements. Additionally, it should factor in the cost of service and time associated with technical debt.

If you want to ensure success, start by reducing tech debt. This will help prevent potential issues from arising and ensure that everything goes according to plan.

Tech Debt

Understanding how to manage a project is a process of looking inward and considering the cost of decisions. By turning this focus outward, you and your team can decide when and where technical debt should be placed in a project.

Ward Cunningham, one of the 17 authors of the Agile Manifesto and creator of the Wiki, is credited with coining the concept of Technical Debt.

Tech Debt is an implied cost of taking shortcuts in the development process instead of investing the time and effort to create a more robust solution. It also refers to revisiting code and making improvements as usage and experience with the codebase increases. 

“With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.” – Ward Cunningham

In that case, tech debt does not refer to debacles. They are simply debacles. Tech debt is a more considered and manageable concept as part of development.

Tech debt can lead to missed deadlines, cost overruns, or even project failure if it is not managed properly. As a project progresses, tech debt can accumulate and become more difficult to address. Consequently, the amount of work required to complete the project increases beyond what was initially planned for, leading to delays and potentially blowing out the budget.

This may include introducing new features to an existing codebase, shifting development team members, changing suppliers, resolving issues or patching security vulnerabilities.

By not addressing this tech debt, the delivery of features and functionality is hindered. This can lead to increased costs in terms of personnel and potential bugs that may be introduced. It can also result in inaccurate estimations which could give competitors an edge in taking over a product or brand’s niche. All of these factors could contribute to increased team stress.

Releasing code into the live environment can be a risky endeavour. If changes lead to unexpected outages or failures, it could result in financial losses, ill will and even legal repercussions.

Product managers or business owners may be aware of the consequences of carrying technical debt, even if they don’t refer to it as such. The issue is that they often underestimate the costs associated with taking on large amounts of tech debt – which could be a long-term financial burden or require a large amount of time and resources to pay off in the short-term.

Tech debt must be managed properly in order to avoid costly delays, cost overruns, or even project failure. 

In the next article, we’ll explore different platform options and discuss when you might choose to incorporate them into your project – like picking the right tool for the job.

Go to Part 3


What have I done for you lately?

New Year 2023 Edition

This post is a laundry list of odd and interesting things that we’ve had to do for clients in the last few months, either as a standalone or as part of a bigger projects. It’s worth reading as it will give you an idea of the types of things you may need help with and be able to apply to your own business projects.

  • Facebook Click ID:
    We prevented the Facebook Click IDs showing up as separate pages in a client’s Google Analytics.
  • SMTP Mail Server, WordPress and Google Workspace Domain:
    We had to set up WP Mail SMTP as our client uses Google Gmail as their mail management software and also Google Docs. This required installing the WP Mail SMTP Plugin, configuring a cloud App using the Google Mail API, OAuth Keys and then configuring the plugin. Once the plugin and App were configured, the plugin highlighted that there were some extra domain records required, SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance). All have an impact and the authenticity of mail being sent from a particular domain.
  • Branding and Briefing Design Services:
    We helped a client navigate the graphic design and production process when they wanted to freshen up their logo. When it comes to graphic design the brief can be as important as the design, to not waste money and get a result that works for you.
  • 301 Redirects:
    We’ve been upgrading a client site and as part of the upgrade we’ve been fixing just a few of the URLs to make them more search friendly. As part of this the changed pages have to have 301 Redirects so that search engines know they have been changed and are not missing. In the AllinOne SEO plugin for WordPress there is an extension that manages 301 Redirects in the WordPress console.

Broken. A Story of Online Development – Part 1

This 4-part series provides a useful primer on how to approach technology and manage its integration into a business, with the aim of avoiding unexpected costs and issues.

How to avoid trouble

I’m not an absolutist when it comes to technology. Everything works some of the time. However, some legacy systems are held together by code that is between 10 to 25 years old, (63 years in one exceptional case). Given some of the ‘kludged’ together code, the market seems pretty OK with a significant slice of ‘broken’.     

That’s not to be arrogant. It’s remarkable that anything works at all. It’s a testament to the hard work, creativity, and market forces that have driven development forward.

All software platforms have their own unique set of challenges that can arise from years of development. This is an unavoidable consequence of the debt that accumulates over time. This is part of a phenomenon known as Tech Debt. 

It’s all how you look at it. All software platforms can, and do have flaws. Legacy bugs and issues introduced over years of development. 

When you use a particular platform for development (e.g WordPress), you can either accept the associated tech debt or plan for it. On the other hand, the platform may save you time by providing features that would otherwise need to be built from scratch. Depending on your project, you can live with it, and/or plan for tech debt.

At other times, the lack of a feature, or its failure to function properly, can be the downfall of a business venture.

All code languages are abstractions of the binary (01010101) or assembly language that a computer chip uses to process instructions. No matter how much effort you put into building your project with a particular language or framework, it will still have tech debt associated with it. 

Many online articles are absolutist and present a world of ‘this’ vs ‘that’. They present a development universe where picking a particular platform (e.g. WordPress) or supplier, is the first step. Without the right planning, this is a poor choice.

Sometimes there are developers who like a particular product because they know how to use it. Thus, even if an article contains a lot of great information about a platform, it has an undercurrent of shilling for that platform.

There may be a temptation to dive in and use the software platform without any forethought, believing that the software platform will be enough to get the desired outcome.

Sometimes there are developers who like a particular product because they know how to use it. Thus, even if an article contains a lot of great information about a platform, it has an undercurrent of shilling for that platform.

When considering the implementation of a new platform, it is important to consider its impact on the business beyond just the technical aspects. This includes evaluating how the work will be consumed, what changes may need to be made to existing business processes and resources, and any potential effects on revenue.

When it comes to starting your project, there will be both positive and negative aspects to consider. Planning how you are going to ‘consume’ the project (integrating it into a business), navigating the pros and cons of different platforms, and strategies for managing tech debt will be essential for success.

In the next article we’ll talk about what it means to ‘consume’ a project and what ‘tech debt’ is.

Go to Part 2