Hardcode or Buy – the return on investment question

Oct 21

Hardcode or Buy – the return on investment question

What elements are best to hardcode and what should be “bought”?

Product teams always have a backlog of features, fixes, customer requests and re-rewrite/re-factor advocates.

At the same time, customer churn, engagement, monetization are the primary product goals that map to company OKRs.Β 

We used to hardcode emails, now that would be crazy

Retention-driven growth needs multiple inApp and out-of-band initiatives. One out-of-band example is customer emails (drips, newsletters, transactional).

Back in the 2000s product teams used to get the developers to hardcode their HTML emails. Over time it was realised that this was a huge waste of developer time and stopping them making a better product!

So the craziness stopped and now we have a massive industry of products like Mailchimp, CampaignMonitor, Autopilot, Sendgrid etc etc that full-fill the need far better than any in-house initiative.

Today very few companies would make the “build” decision and prefer to use a SaaS platform product that makes email creation and sending easy – its a no brainer!

Should Apps hardcode inApp engagement?

Moving any task from backlog to sprint should be sanity checked against the one question:

“Is this our core business?”

For most products, if your product needs:

  • Guides,
  • FAQs,
  • Tooltips,
  • Announcements,
  • Feedback,
  • Videos

Then, the answer is NO.

For some companies, for example gaming, every user moment needs to be hardcoded and controlled. The financial stakes for conversion are measured in milliseconds and their ad-spend is huge so they need to capitalize. With tens or hundreds of developers and many millions invested – this is a core competency for the Apps survival.

For most companies, however, the core competency is the functionality of the product and ease of use. As we discussed elsewhere, this is why we discuss a:

  1. Feature layer (App Design layer)
  2. Engagement layer
The Pointzi Engagement Layer

The Feature Layer – changes with the speed of sprints. It is owned by the developers and should change slowly.

The Engagement Layer – should iterate rapidly. This is where Product Managers and growth teams can iterate and learn what creates retention and feature usage uplift.

The launch (to customer) cadence for each would look like this.

The Business Case for not hardcoding

Once you start with engagement layer activities you are super-sprinting and measuring much faster than your feature sprints can. You may eventually hardcode something that has been successful using Pointzi – giving you more fine-grained control, but you didn’t spend person-months building something that nobody cared about.

This table shows our recommendations when establishing a business case:

  1. Stop wasting developer time.
  2. Speed up your learning iterations
  3. Target and measure users at different phases of the journey – don’t spam everybody with popups and announcements!
Hardcoded Pointzi Platform
With Hardcoding, every single tiny change requires App (web) & Appstore (mobile) releases
With Pointzi, changes are instant or scheduled to users πŸƒβ€β™€οΈ
With Hardcoding, you need to stop developing features πŸ€•
With Pointzi, you don’t bother developers πŸ™Œ - keep making your product better!
With Hardcoding, you’d have to code user targeting (yep, more code) 😱
With Pointzi, audience targeting is point-and-click and real-time 🎯
With Hardcoding, no analytics πŸ€·β€β™‚οΈ
With Pointzi, guide interaction analytics are built-in πŸ’ͺ
In a business case, numbers speak louder than words – so contact us if you’d like to make use of our spreadsheet and add your unique numbers and resources. The spreadsheet isn’t too pretty but its enough to make a data-driven business case.

For your:

a) developers. Some developers have a “not-invented-here” view that is disconnected from commercial reality. Especially with outsourced or offshore contractors, they may have a tendency to want to “build everything” even if the work is demeaning to their talents and time.

b) management – they carry the burden of costs.

You can also point them to this video – in 7 minutes it summarises the points discussed here and may be quick enough for them to review to have an informed conversation.

So, if you need help with your build vs buy decision – either a discussion or quantitative model, hit us up in an email or the chat widget.

You can also fill out a request on the Contact Us page.

To understand what functions the platform provides, check out some of the video examples.


Banner image credit: https://corporatefinanceinstitute.com/