A Web Stats System is Liberated

Martindale-Hubbell

The Problem

A web stats system, collecting key information about ad metrics, had become troublesome to maintain and expensive to run. Complex business logic necessary to translate raw event data into meaningful reports was embedded in opaque database functions.

Our Solution

We observed that the business logic of the application was too complex to be defined in database functions. A more appropriate home for such logic was a web application coupled with high test coverage. We built a tool which showed us discrepancies between the output of the system we were building and the existing system. As we migrated functionality, we continually compared old and new behaviour and adjusted our solution to suit. We included reporting tools in our app to allow us to look at the data we were transferring. We included tools in our implementation which allow for convenient review and fixing of problematic incoming data. We launched our re-implementation without any disruption to the system.

Proven Results / Value Add

Our client let go of an expensive DB license, which reduced operating costs significantly. Stats collection and report generation was able to continue, and iterative development of the application was able to start as the codebase was conveniently extensible.

A Rebuild. But how?

Nolo

The Problem

A product in our client’s suite was showing signs of technical debt. Inflexibility, slowness and bugs were dampening enthusiasm across the board. We performed a code audit, which quickly showed that a rebuild was necessary. But whether or not to rebuild wasn’t the pertinent question. The question was: how? Significant parts of the product used tooling which could be found elsewhere. It would save much time to reuse rather than reinvent the wheel. Every stakeholder had a different opinion on what was the best way forward.

Our Solution

An evaluation of options was necessary. With so many options to choose from (and the same number of stakeholders to convince) we had to take extra care to be scientific in our assessment. We formed a set of questions that could be asked of each approach. The questions covered topics such as feature gap, extensibility, deployment and integration with other systems. Our research was based on composing answers to these questions. We delivered a PDF report discussing each option under a common framework, along with our recommendation on which to proceed with.

Proven Results / Value Add

The team chose the option we recommended. We went on to build a proof-of-concept in quick succession. Full product development is now underway on the rebuild. We were able to leverage existing open-source tools in order to implement two significant parts of the new product.

The Problem

Tasked with re-building an existing product, and having chosen open-source tools to provide parts of the new implementation, we found ourselves in an interesting situation. We wanted a prototype to verify that our chosen tooling would indeed work within the bigger picture of the entire product. We also wanted to demonstrate certain user journeys using our chosen tools. It wasn’t clear that a UX prototype built with a tool like Figma would convey this adequately.

Our Solution

We built a proof-of-concept of the product with code. We kept the scope as focused as possible. Rather than build out a backend, we mocked application data in order to support the journeys we wished to demonstrate. When complete, one key and non-trivial user journey using the tooling we had chosen was demonstrable.

Proven Results / Value Add

Prototyping with code is risky as it can be time-consuming. But with our focused scope and use of mocking, our two-person team built the proof-of-concept in less than a month. All stakeholders experienced an “aha” moment in which they saw how the tools we’d chosen would work in the new product. But further, stakeholders could actually use the proof-of-concept themselves. Because we had deployed it to a staging environment, they could play with the implementation and become comfortable with it. This gave everyone confidence in our direction, and allowed us to proceed to continued product development.

Open-Source APIs for Public Domain Information

GovWizely

The Problem

GovWizely were tasked with making many data sets publicly accessible via standardised HTTP APIs. These data sets were stored in places and formats which were difficult to access and decipher.

Our Solution

Our team build a web application which read a data source, transferred the data into an accessible format, populated this data into Elasticsearch indexes, then made the information available online via HTTP APIs.

Proven Results / Value Add

Many data sets containing useful personal and business information became accessible to the public. GovWizely was able to deliver on their commitment to provide this service.

Rails Web Framework Upgrade

Full Slate

The Problem

Full Slate was serving thousands of businesses daily, but a major piece of technical debt had been present for some time: the app was built on Rails version 2.3, which had been end-of-life for more than three years. The ask was to upgrade to the latest version (5.0 at the time).

Our Solution

We formulated an upgrade roadmap and testing plan. We upgraded one version number at a time, ensuring the app functioned and tests passed before continuing to the next. We captured errors in a tracking system, so that we were aware of every little problem that QA, Product and ourselves encountered when testing. We undid monkey patches which had been added to deal with the older Rails version, and straightened out many gnarly things like composite primary key usage, home-grown asset compilation and dynamic routing. After six months we delivered with minimal disruption and fanfare.

Proven Results / Value Add

This project provided the groundwork necessary to get development restarted on the product. The months (and years) which followed saw many new and significant features being built, allowing the product to remain relevant and keeping the extensive user base it had grown happily engaged.

The Problem

EssayJack came to us with a MVP. Their app was supporting a small user base, but it had a number of concerning problems. They were keen to understand why these problems were present. They wanted to make judgement calls on how next to proceed with product development. They were also keen to find a consulting partner to take ownership of the technical development of the product.

Our Solution

We took a detailed look at the app’s codebase, deployment and technical processes. We documented the things that were done well. We listed out where the app could be improved, and why the concerning problems highlighted to us were present and how to fix them. We compiled all this information in a PDF report, written for an executive audience.

Proven Results / Value Add

The audit shed light on the root cause of many of the app’s problems. It created a backlog of technical debt repayment necessary to prepare EJ for future growth. This lead to Rapid River going on to completing many items from this backlog. EssayJack become stable, was able to support an increase in new user activity, and provided the groundwork for EssayJack’s eventual rebuild.

Rapid Integrations on a Plug-In Friendly Dashboard App

Dasheroo

The Problem

Dasheroo were a start-up with a viable business idea: to provide a place were digital marketers and business people could see metrics from all the online tools they use in one place. The problem was that in order to build this, Dasheroo needed a build large number of integrations with their product.

Our Solution

The engineers at Dasheroo built a platform which supported integrations in a pluggable fashion. In order to add an integration, all a developer had to do was to write a plug-in for the application. The process of writing a plug-in was well-defined and standardised. It was convenient for us to “go to town” writing plug-in for Dasheroo. Before long the product had a volume of integrations necessary to make it a viable contender in the marketplace.

Proven Results / Value Add

Dasheroo went from a proof-of-content to a fully-fledged MVP, ready to woo customers and meet revenue targets. This was possible due to the large number of integrations we added to the product.

Clickstream Ingestion System

Internet Brands

The Problem

Our client wanted to capture user activity across the many websites they operate. A clickstream solution (JS snippet, API, message bus) seemed like a straight-forward solution to implement. The catch? They anticipated around 2000 events per second during peak times.

Our Solution

We built a simple solution with high-scale needs baked in. Our JS snippet was designed to work in an extensive range of browsers (with automated testing via BrowserStack to boot), under no circumstances impeding user experience. Each component in the stack was clustered for redundancy and to support horizontal scaling. Components were observable, allowing us to monitor the performance and health of the system constantly.

Proven Results / Value Add

The collection of this information opened a window to cross website user activity. This allowed for the creation of user segments for marketing purposes, and for various personalised user experience efforts to get underway.

The Problem

Avvo had a typical problem - a substantial tech team, who were busy with many important deliverables. The trouble was that certain operational aspects of the product were being sidelined. The area most hit was Sales. There was a growing list of items that the Sales team needed from the Development team, but not enough people free to help.

Our Solution

We ramped-up as members of the Development team, joining existing efforts and participating in team workflow. We then oriented ourselves towards the Sales team. We formed a Scrum around their needs, having people from Sales function as Product Owners and as direct stakeholders. Our efforts fitted into the existing Development team’s workflow, but ensured that a significant amount of Sales-specific development tasks were completed in each Sprint cycle. We called our approach “SalesLuv”.

Proven Results / Value Add

The Sales team went from feeling frustrated to feeling liberated. Many seemingly minor items were cleared out of their path, transforming their processes from cumbersome to convenient. Morale went up, followed by revenue.

AMP, with Dynamic Content

Avvo

The Problem

AMP was becoming a major contributor to the ability to attract traffic from search engines. It was important that our client establish AMP versions of key content pages on their platform. But these content pages needed to serve a variable number of ads from an internal ad system. The challenge was to continue to have these ads show on AMP, a framework which imposes a high degree of constraint on page design and attributes.

Our Solution

We built AMP versions of the pages. We had to get creative about how to place a dynamic number of ads on a page that was served with static content in mind. Through the use of AMP caching rules and knowledge about how many ad spaces would be filled per page over future 12-hour periods, we were able to implement a solution that worked with the existing internal ad system.

Proven Results / Value Add

With AMP in place, traffic from search engines saw an immediate and significant uptick. This led to a boost in revenue from ad sales and an increase in search engine ranking.

Talk to us about your project

We work on long-term projects and build lasting relationships with our clients. Tell us more about your product and how we can help you.

Hire us