This is the second in a four-post series about FrontlineSMS and its closing - you can find the first post here. It draws inspiration from this announcement by Robyn Vinter and this series by Laura Walker McDonald (my wife).
There are, perhaps surprisingly, more than a few ways to describe Frontline as a business - starting by saying that FrontlineSMS has never been a literal business. Broadly speaking, there were three phases in Frontline’s business history - each characterized by a unique market and strategy, novel challenges, and a new company. And, at each stage, our read of the market, the opportunities, and the resulting approach were unconventional, bordering on counter-cultural. That started before I joined Frontline and was something that we wore proudly throughout our work. It’s fair to say that those choices were key to what we became - and to why we’re closing.
The purpose of this post is to explain our growth, the insights of our market exploration and experience, and convey some hard-won truths over the years. We, eventually, reverse engineered a business model for Frontline - and one that kept us in the black most of the time. So, it’s possible. But as a lot of things, including our choice to close, should indicate - it’s hard to recommend. This post isn’t a comprehensive history, it’s an attempt at sharing the value of the experience.
It’s also important to get the ugly part out first - this is on me, Sean McDonald, the individual. Lots of people contributed to building Frontline, including in ways that meaningfully improved and/or saved the business. But market analysis, strategy, and business development has been my responsibility at Frontline - for at least the last 9 years. And I... never really had any training or ambitions to run a business. And on one hand, we’re closing - which is pretty good proof that maybe I shouldn’t have. On the other, there are a lot of organizations who were adjacent to us that followed more traditional entrepreneurial models and, for those that are still around, became pretty distant echoes of what they set out to do. These choices - ours and theirs - were personal and political, expressed in the financial, operational, and technical execution of our work. My last post will try to explain the things I’ve learned about this work and myself, mistakes I made, and how difficult it is to manage the balance.
For this post, regardless of whether you think I was “right” or “wrong,” here’s an honest account of what I was trying to accomplish at each of the three stages of our development, how it went, and the most useful takeaways from each stage. Our path led us, as a business, from a philanthropically funded public interest technology to a social impact service design consultancy to an social enterprise focused on using our open source messaging platform to improve public, civic, and humanitarian services. This piece goes through each phase of our history - kiwanja, the Social Impact Lab, and Occam Technologies, and uses our experience to explain more broadly applicable dynamics and lessons.
First, let me quickly set a few baselines/framing points for our work:
We were more of a thesis and vehicle for social change than we ever really were a business. The first vision of that change was Ken Banks’, Frontline’s original founder, to build tools that were proactively designed to enable last-mile use. The second and third versions were that we could improve the equity and efficiency of vital services by translating them into SMS, because of its broader adoption. The people, business, and community that we sought were always based on those visions and our pursuit of revenue was largely about building infrastructure to serve the scale, impact, and resilience of realizing each vision.
Running an organization that builds and maintains a customer-facing, open source software platform is different than running organizations that do other things. I’ll describe more in the platform post - but we were constantly balancing five, competing, infinite needs, all of which were (in non-profit parlance) overhead costs: (1) stability and scalability of the platform; (2) sophistication of data management and features; (3) configurability; (4) usability; and (5) external dependencies and edge cases. And user expectations of each were endless, regardless of whether things were free and open source. Unlike other forms of social good work, product work also has to have coherence and continuity across all of its outputs - while doing the continuous maintenance work necessary just to keep something working on the Internet (and, for us, off of it).
It is hard to overstate how much people disregard SMS as a platform. SMS is the most-used two-way communication platform in the world, bar none. For the entirety of my 12 years working at Frontline, people have asked me what we’re going to do when SMS dies. For context, SMS right now has an active user base of 5.22 billion - ~1 billion more people than the entire Internet, and significantly more than actually use the Internet. Predictably, the digital services that are designed based on the assumption that everyone uses the Internet also fail to serve the people that make up those gaps, which disproportionately affect women, rural populations, and the poor. The way that we build digital systems, somehow, continuously deprioritizes SMS and the equity that its greater adoption enables, usually in favor of speculative, technosolutionist workarounds. SMS has never been a cutting edge technology - but the technocratic snobbery that’s been debating its validity for the last 15 years, while it has maintained a nine-figure+ adoption advantage over the entire Internet, has created a lot more digital divide than it has ever solved. SMS’s absence in most modern digital systems and digital rights conversations should be an embarrassment to public interest technologists, designers, and service providers - instead, 25+ years in, we’re still designing services that explicitly exclude the already marginalized. No matter the evidence or the equity arguments, we found that there are limits to how much demand you can create for a type of systems change, simply by building tools that reduce the barriers to that change.
There’s a chicken-and-egg problem in public interest software pricing. The more expensive a product, the fewer people who can use it. The cheaper a product, the harder it is to maintain and improve. The balance a company chooses, typically, determines their primary market - and we found that it is significantly harder to jump or bridge markets than it is to build a product capable of serving multiple markets. What people talk about less often is that the same is true for how you finance selling a product - it has to be expensive enough to be worth individual sales attention, cheap enough to build a critical mass of low-need users, or free with a subsidized business model. What we (and other businesses like us) missed is branding. Most people understand technology platforms by the branding the company projects, including who a platform serves. Branding is more important to market selection than what a platform (technically) does, the pricing model it uses, or where it’s based - and we significantly under-estimated how expensive it is to shift markets. As a result, the majority of platforms end up being defined by who they market to first - for Frontline, that was last-mile markets with a free, open source product.
Most people think of designing a digital service like building a car: it may take a lot of initial work, but - at some point - you decide it’s “done” and then it just “works forever.” It might need some light tweaking, but rarely anything serious. That was never our experience - nearly all of the services we designed were more like launching a magazine: getting the machinery in place was almost never the hard part - it was almost all building relationships, setting clear expectations, and creating reliable value, in-context, over time. While there’s a decent amount of recognition of adaptive/agile methods, iteration, and the experimental nature of service design in engineering circles, most people conflate product design with effective service design and - to put it lightly - they are not the same thing. There was a bright line difference in success and satisfaction between clients that approached service design with the latter approach, and those that expected the former.
We made technical choices based on what would reach the most people, at first because it was the only way to reach last-mile markets and, eventually, because it led to the most resilient, replicable tooling. Frontline started with a strong understanding of the ways that the design of digital tools could make them inaccessible and so, whenever we were confronted with a decision with impacts on where our tool could be used - we tried to build features to be as equally useful and globally extensible as possible. That, when it comes to global mobile connectivity and digital payment processing, is a much larger challenge than it seems - and was even larger in the mid-late aughts. We did this despite most of the advice we got and it had important, mixed results.
Alright, let’s get started.
The kiwanja Years (2005-2011/12)
Ken Banks created FrontlineSMS as an open source technical product which, by his own account, surprised him with its popularity. FrontlineSMS was first used by Zimbabwean human rights organization, Kubatana, and then later at national scale to help coordinate the monitoring of the 2008 Nigerian election. Ken’s vision for FrontlineSMS was rooted in, primarily, two things: (1) resilient design, optimized for uncertain infrastructure and accessible configurability; and (2) open source and community - creating forums to enable users to share the load of maintaining and supporting the product. Ken’s vision was very compelling and, in a lot of ways, remains a grail in the open source community. In the early years, Ken received support from a number of large philanthropies, which necessitated the creation of “FrontlineSMS” as kiwanja, the non-profit 501(c)3 and, critically, growth.
During this period, kiwanja evolved from a one-person organization, externally contracting our software development, to a team of ten, a thriving global community, and an explosively popular product. Inside the organization, Ken was building the team with talented anchors in core areas - Alex Anderson as technical lead, Ryan Jones in business development, (my now-wife) Laura Walker McDonald as community and operations lead. Outside the organization, Ken was a recognized leader of the Information Communication Technology for Development (ICT4D) community and its growing recognition of the importance of mobile technologies. The platform was being downloaded around 15,000 times a year, and we had an active backlog of improvements to keep everyone busy. We were, happily, dependent on philanthropy and community, with a useful product that mostly nice people were using to do good and important things in the world.
Philanthropies are always a politically complex source of support, but they enabled Frontline to become any of the things that people remember. That was a choice that we, as kiwanja, made - and so when we talk about the impacts of trends in philanthropy on the organization, the goal is not to criticize specific institutions, but to explain our customer market and our response.
At this point, three things about our work began to change in ways that shaped our future: (1) we ran into the technical/non-technical user divide - we were popular with creative technologists, but most of the people with the authority to design services didn’t understand what you could do with SMS as a service design layer; (2) we started to fall out of alignment with donors - we felt a big funder push to a particular vision of scale, user surveillance as ‘proof-of-impact’, and exponential plans for revenue; and (3) our products and tools were being used in contexts and at a scale that pushed us well-beyond any established guidance - not just for technical reasons, but an enormous range of ethical and legal issues.
With funder support, FrontlineSMS began launching “Projects” - micro-enterprises that modeled, implemented, and advocated for the use of SMS in specific industries. Josh Nesbit and Isaac Holeman, started FrontlineSMS:Medic in 2009, now Medic, demonstrating the value of messaging in last-mile healthcare extension. This became our model - we would find a brilliant person or team that wanted to work on building SMS services using FrontlineSMS, and work together to raise grants to build organizations. The plan was for each project to grow its own, independent lines of business - with kiwanja becoming an incubator-style home and launch pad. This model worked for a number of years - we launched the :Medic, :Credit (mobile banking), :Learn (education extension), :Radio (interactive programming), :Legal (legal aid extension - and also how I joined the organization), :Governance (public and civic services), :Media (journalism), and… I think that was it. The incubator model gave us a lot of flexibility, a path to growth, and coincided with the philanthropic turn to tech entrepreneurialism as a model for social change.
But we were bursting at the seams. And being pulled in every direction. At a basic level, our value proposition was being able to build and lightly automate tools in last-mile markets. But, because of our popularity - our products (and, to add complexity, our brand) were being used in an impossibly broad range of markets, using an even broader range of hardware, for an even broader range of things. And the tech could do a lot of that, but it couldn’t do it with the degree of configurability, scale, sophistication, or stability that everyone wanted because - they all wanted different things. Similarly, the open source approach meant that we weren’t able to meaningfully set expectations, monitor, or quality control the use of FrontlineSMS. And, as a result, we were getting the reputation for our tools ‘not working’ - often because our tool was the user interface for a much more complicated stack, not because the software wasn’t working. But, in some places, the software also wasn’t working.
In this vision of our work, FrontlineSMS’s code base and roadmap were a common-pool resource (cough, digital public infrastructure) - and we would manage new features through a shared roadmap, forks, and federation, as necessary. I’ll explain more in the platform post - but this model, even inside our relatively small organization, never worked at a technological level. The Projects that developed unique functionality typically did so on forked codebases, instead of becoming core platform improvements, while the costs of maintaining broad configurability were significant and largely fell on the core team.
The development team was underwater with service requests for a platform that didn’t cater to our increasingly non-technical, enterprise users. Similarly, Frontline was dependent on successfully interfacing with driver software for USB modems which, I’ll say politely, was a very non-standardized platform environment. Our project teams were discovering, industry by industry, that technology was not the primary reason last-mile markets weren’t being served - and launching a good product wasn’t enough to change most service market priorities. SMS management as a technical functionality was often viewed as a component of multi-channel services, which required product specialization. Our funders wanted us to launch new products and, eventually, new projects - without any real ongoing interest or support for the product or projects we had launched. At the same time, smartphone adoption was growing. There is/was a mobile app speculator’s goldrush and the persistent presumption of proximate, ubiquitous mobile Internet - both of which drew attention away from both older technologies and sensible digital service design, generally. This was adding up to us needing to deeply invest in the depth of our core product and community while continuously selling new product and feature extensions - all while watching our philanthropic supporters move on to the next set of strategic priorities.
In response, we made a series of decisions that began the end of the kiwanja era. First, we decided to begin a consulting business - mostly because people were asking us to, but also to diversify our revenue away from grant income and to help leverage the expertise we were gaining from working where and how we did. The second is that we rebuilt FrontlineSMS from the ground up - this time, toward increasing stability and a quickly followed-up move to the cloud. The third is that we tried to formalize the organization. Frontline had grown quickly and mostly begrudgingly and, as a result, there was a lot of organizational and procedural infrastructure to build. That also meant formalizing things with the projects - some of which chose to become part of the core company and some of which spun out to form their own enterprises.
We were also starting to be recognized for the first phase of our work - Ken won an Ashoka Changemakers Award, FrontlineSMS won a Curry Stone Design Prize, and the team had won a Knight News Challenge Award, among others. By the end of this period, FrontlineSMS was up to about 25,000 downloads a year.
There are a few lessons from this era of our business -
There is a difference between being culturally open source and maintaining or improving an actively used product through code contribution - and we were definitely the former. We experienced a big, largely undiscussed, cultural difference between technical open source products and GUI-style open source products, largely to the detriment of last-mile and non-technical users.
The amount of responsibility a company takes for the impact of the use of their product is a political choice - as is how it exercises that responsibility. There are difficult trade-offs and dangerous extremes in all directions.
There is an inherent tension between trying to centrally maintain a ‘public interest’ technology stack and the depth of ‘interest’ a product is able to achieve. At this point, product-market fit - especially in public services - is not about functionality, but about the brand, focus, and priorities of the implementer (all of which shape and change the experience of using the tool). This is also true for the amount an organization invests in ensuring that a technology is being used in the ‘public interest’ - a term which is inherently political.
The Social Impact Lab Years (2011/12 - 2014)
The name “Social Impact Lab” came from a lock-in session where Ken, Laura, and I relentlessly debated what it was that we were doing with FrontlineSMS - one of my absolute favorite professional memories. What we came to was intentionally literal - we saw ourselves as becoming an organization that was facilitating a range of social impact initiatives and experiments, based on the use of mobile technology. Our logo was a SIM card and test tubes (filled like bars of connectivity). And, while that probably sounds jargon-y, it turned out to be a big shift for us. We went from prioritizing FrontlineSMS the product to prioritizing the effective use of FrontlineSMS as a product, which became a big source of mission creep.
Our overall business strategy had three, core elements: (1) continuing to seek grant funding to launch projects and/or product features in new verticals; (2) managing the transition from grant-funding to earned revenue through software-as-a-service revenue and project-based contract work - with an initial focus on the international development sector; and (3) using consulting as a business development tool (and buffer for) the transition to product-based subscription revenue. We were, essentially, pivoting nearly everything.
In a lot of ways, it worked. We launched version 2 of FrontlineSMS in mid-2012 - and it was a step change in scale (again). We went from 25,000 downloads to 250,000 downloads. By the end of 2012, we’d also launched a cloud-hosted version of our software - which was to become a lynchpin in our business strategy. We built and launched FrontlineSync, a free and open source mobile gateway app that helped us get away from the problems of the modem ecosystem (by trading them for the challenges of the Android ecosystem). Our team had grown and we had offices in Washington DC, London, and Nairobi. Our broader geographic spread enabled us to move into international development communities and consulting - a new market, model, and source of revenue. In 2013, we were recognized as the #1 Technology Non-Profit in the World by the Global Journal and won a Google Impact Award to work on land-titling with Landesa - which had been a personal dream of mine and was the largest single financial award in Frontline history.
And, in some important ways, it didn’t work. Our consulting work was increasingly based on our service design and last-mile implementation experience, and less directly related to maintaining or using FrontlineSMS as a software. Contributing to broader knowledge and policy dialogue in the space was good practice and business development, but required us to build an almost entirely separate internal set of business processes. The organizational structure of a last-mile digital development and design consultancy is different than the structure of a successful SaaS business - and they are in direct tension. Development consulting is overhead-constrained, software businesses are largely driven by overhead costs (development + marketing) - not to mention the very uncomfortable data governance/donor reporting propositions. And we didn’t help ourselves - between geographic spread and revenue diversification, our organizational structure got too complicated, which cost us in donor diligence and operational overhead.
Running a cloud-based service focused on last-mile markets also presents unique challenges. One of the difficult decisions we made was to shut down our community support forum - the unfortunate truth is that while the forum was culturally important, like our code being open source, the practicalities were extremely taxing. Our team was spending more time trying to maintain the quality of technical advice in the forum than it took to provide direct (accurate) user support - and our move to earned revenue made the margin too expensive. Our team also had to constantly debate fundamental tensions between equality of service provision and ease of use - for example, it is substantially easier (especially internationally) to set-up a mobile connection in most places using a third-party service called an ‘aggregator’. But, there aren’t any aggregators with global, two-way coverage - so, we tried to integrate with as many aggregators with unique coverage as possible, but inevitably missed places and carried a significant ongoing maintenance burden. Similarly, online payment providers don’t enable payments from a lot of the places we worked. It might sound mundane, but ultimately had a big impact on who we were able to serve, and to what depth. We found ourselves with slow, growing success in each of our core areas, but struggling to maintain cohesion across our lines of business. And, importantly, we were hemorrhaging unrestricted/core funding - not only spiraling through ‘the non-profit starvation cycle’, but also struggling to convert free users to paying cloud users, while continuing to absorb the costs of maintaining an open platform and without any marketing budget or support.
We were starting to need a cash infusion that neither our grantors, our subscription revenue, nor our consulting income was positioned to cover. At the same time, there was a significant push for ‘public interest’ technologies at the time to turn to ‘impact investment’ as a scaling/philanthropic off-loading strategy. We went through a series of professional, largely absurd, financial valuation processes and spoke with most of the ‘international tech for good’ investment funds - mostly to be told we were either too established or not established enough, doing work of unprovable impact or too obviously proven impact, with technology that wasn’t innovative enough or too obvious to be considered innovation. As an example, the financial valuations of our product ranged from $200,000 to $20m - mostly depending on what theory of comparison they used (one theory was, no joke, the number of lines of code). By the middle of 2014, we were doing strong programmatic work but had to confront a few related, concurrent truths - with the starkest being that - without a cash infusion, we were going to have to close - embarrassingly, at what felt like the height of our success.
Instead, I raised a “friends and family” round and, essentially, took Frontline private. Just as with the previous transition, there were a few areas of ongoing overlap - but the big moment happened in November of 2014 when, after an independent Board of Directors review, a new company that I owned - named “Occam Technologies” - purchased FrontlineSMS’s brand, technology, and the employment rights for the technical team. Very little about that process was simple - and it probably merits a history unto itself - but it enabled us to successfully split the businesses and practically ended the “Social Impact Lab” era of FrontlineSMS. Social Impact Lab went on as an independent non-profit think tank for three years, before closing.
A few lessons (in no particular order) from that era:
Grant funding and international development are extremely relationship-driven and largely cost-prohibitive for small organizations, but unlike regular client work - they proactively dictate your margins, require significant education and relationship investments, and involve artificially extended contracting processes. My early perception that this funding was cheaper or better than other sources of revenue was naive - though philanthropic funding was integral to Frontline’s establishment and growth.
From a services perspective, we were not in “a” market - so much as the last-mile of 1,000,000 markets, each of which were achievable but (mostly) commercially unsustainable. We survived by being able to pivot between markets and serve those that were receiving atypical attention and resources, as opposed to choosing a specific vertical or service and building market presence and/or recurring revenue. Our product’s re-usability was the most important design feature in preserving our longevity - though it also, perhaps ironically, enabled us to avoid having to invest a specific service market and/or revenue model.
The hype cycle(s) are real. During the kiwanja years, the buzzword was ‘information communication technologies for development’ (ICT4D), during the Social Impact Lab years, it shifted to ‘mobile for development’ (M4D), as predecessors to what became as more local/domestically framed ‘civic tech’ (now ‘public interest tech’ and/or ‘digital public goods/infrastructure’). No matter the name, there’s no nomenclature or technology that gets a social change project around the need to (or costs of) build equity and legitimacy in-context. I cannot tell you how many projects make substantial investments in collecting data that they have no meaningful use for, subjecting people to risk they have no plan to secure or mitigate.
Occam Technologies, Inc. (2014 - 2021)
Occam Technologies was named, perhaps obviously, after the philosopher behind Occam’s Razor, which says that the shortest distance between two points is a straight line. He’s also credited with (a longer version of) “I’m sorry I didn’t have time to be more brief,” which is also a bit of a commentary on digital service design. The brand thinking was: the simplest bridge between two people was a message. Our intention - for ourselves and our clients - was to increase impact by simplifying things to their core elements. Compared, at least, to what we had been doing.
At a structural level, we had three main categories of users/clients: (a) subscribers to our SaaS service, who were largely self-supported; (b) organizations that needed our help in configuring the SMS workflows, but then largely self-managed; and (c) organizations that needed custom development and hands-on project design (or implementation) support. Our strategy, broadly speaking, was to work with a small number of c-level users - who would ‘buy’ our roadmap and enable us to develop new features; a slightly larger number of b-level users, to help us fund product testing and maintenance; and as many a-level users as possible, whose revenue we used on hosting, service, and (although we rarely got there) interface design. The goal was to use higher-margin work to fund the product design, testing, and maintenance work necessary to make it more accessible. While we went through different phases that attempted to shift the relative prioritization of these user groups - in practice, we pretty consistently maintained approximately the same balance (2-3 c-level clients, 5-10 b-level clients, 50-100 c-level users).
At a strategic level, our work had historically been in humanitarian emergency settings and international development contexts which were extremely difficult to maintain a technology business around. We needed to move from event-based customers - which were expensive, hard to get, and non-recurring - to ongoing, service-based customers. In 2015, we focused on two types of work - both, broadly, ‘civic tech’: political campaign engagement and public service design. We ended up engaging with relatively high-level campaigns, but losing most of the US market to texting platforms that focused on text-banking (a practice built on exploiting messaging opt-in consent rules). We also turned down pitches to a number of political parties we didn’t agree with, which you can do, when you don’t have shareholders. We continued to work on international campaigns throughout the Occam years, but it never became our “focus” any more than any other vertical.
Our aspirational technical value proposition, during the early years, was to build the bridge between conversational messaging and structured data. In reality, our primary value proposition was probably having one of the most configurable mobile gateways in the world (we can set-up a system anywhere there’s any kind of mobile signal/access) and our pipeline was more a reflection of our geographic reach than automation expertise. Still, early in the Occam years, we managed to engage a client that paid us to develop a configurable SMS workflow engine, which became the root of our ‘activities’ and much of our growth. Essentially, we were able to create and host applets inside Frontline that could do complex data management and guide users through conversational interfaces (we called them recipes). At various points, that functionality has been called “AI,” “chatbots,” and “automation,” - whatever you call it, it enabled us to endlessly configure our work with minimal core codebase changes. It was also probably the source of our largest, wrongest business bet.
In typical Frontline fashion, we wanted to help make it easier for last-mile and non-technical users to find, design, and build their own SMS automation. We’d seen (and proven through RCTs!) how effective SMS integration was, and believed that it could be an important source of service standardization and/or creative improvement. After years of watching “everyone should learn to code,” hype - our approach intended to be a more sane middle ground: no-code technology for messaging automation design. By converting messages into things like API triggers, SMS became a navigation window to all kinds of digital interactions and services. In the early years, we made at least three non-technical recipe design interfaces - all of which limited the platform’s potential in what felt like critical ways - that we didn’t end up integrating into the product (in retrospect, we should have released the interfaces). But, it turns out, automation design is a pretty niche, mostly technical interest (similar to the experience of IFTTT, Zapier, and the iPhone app Shortcuts) that doesn’t have a huge amount of novice interest. And, the people who are interested in cutting edge automation are, by and large, not focused on SMS. Nevertheless, we spent the first 3 or 4 years of the Occam era developing an extremely powerful automation engine that, because of usability vs. configurability challenges, we didn’t release as a public feature. Instead, we sold the ability to create and customize our SMS automations, which became the core of our client consulting work and primary source of revenue.
For the most part, and until recently, the automated messaging market went a different direction - either toward simple notifications or ‘machine learning’-based chatbots. And, of course, there has always been the persistent assumption that SMS was going to become irrelevant - from 2014-2018 it was largely because of WhatsApp and other OTT messengers. While SMS was falling from vogue, our app architecture and recipes created another, I (still) believe, significant value proposition: configurable federation.
Essentially, we were discovering that it was really easy to build complex mobile engagement systems that worked everywhere and could be configured to move data strategically. For non-technical readers, most software-driven digital services are a combination of databases (storage), processing functions, and routes between them. Because we had a cloud-hosted platform, a desktop platform, and a mobile app - we could configure systems to run across a more diverse range of tools than most other systems. At a functional level, we targeted our value proposition at organizations that have decentralized operations that perform similar services - like humanitarian organizations, international development organizations and public services. So, an organization could design an SMS workflow and then roll it out, to be administered through each of its branches, but at a standard quality of practice and returning standardized data. That business structure isn’t just how a lot of public service organizations work, it’s also how a lot of commercial franchises work (a market we were never quite able to make the jump into).
In our early years, this was also how we hoped (and pitched for) political campaigns to work - a combination of decentralized, locally empowered leadership with the ability to coordinate and standardize key messages, mobilizations, and data collection needs. Political campaigns then, like many of the organizations we targeted, instead (typically) opted for more centralized systems, with less meaningful decentralization (or federation). Nevertheless, after some initial fits and starts - we began targeting organizations based on two, primary factors: (1) they provide a direct, articulable service; and (2) they exist in an organization and/or industry structure with an interest in standardization.
And it worked! For a few years! We started to work with clients that met those criteria and began charting a clear path to growth. We were working with a charitable foundation focused on supporting community enterprises in the UK, a charter school system that served rural communities in the US, an anti-trafficking legal services provider in Mexico, and the legal aid system in the US. And, on smaller projects, we supported HIV researchers in Congo, anti-malaria campaigners in Indonesia, an interactive traveling museum exhibit in the US, agricultural support projects all over Africa, and disability researchers and wheelchair designers in SE Asia. And then, as happens, the bottom fell out.
A few, pre-apocalyptic observations and lessons:
We always struggled with platform pricing - our goal was for our tools to be cheap, but the trade-off was that our time was expensive. For a lot of clients, that caused understandable whiplash - and it meant that we were selling project consulting to people expecting a software platform. It worked more than it should have, but it only worked when we also had people proactively seeking larger client work.
We didn’t do any marketing, which was stupid. We always believed the quality of our work would speak loudly enough. Our historic approach to marketing was to participate in communities of practice, work with a leading partner to demonstrate the value of SMS services, and then sell to clients who could help us distribute the platform to a wider subscriber base. We couldn’t afford the advertising for the content marketing that was driving SaaS businesses, nor could we afford a dedicated proposal-based procurement team that are common in consulting businesses - but we did small amounts of both. This worked, initially, but we couldn’t diversify or speed progress in each vertical fast enough to avoid, essentially, organizational entropy.
Not every profession needs a software UX trying to make the service accessible to non-professionals. Designing automation is a large, flourishing profession - and our inability to design a non-technical interface we were happy with should have been a clearer indicator that we didn’t understand the target market for that line of work, as useful as it was to our team.
The Beginning of the End (2019 - present)
In the Occam era, there’s basically “2014-2018” and then “2019 - present.” In the late Fall of 2018, we had agreed contracts to grow two important lines of our work - one with government support and the other as an extension with our largest client - and both were, quite late in the process, inelegantly pulled for reasons that were beyond our control. We went from working on an aggressive growth and hiring push to figuring out how to make the most of our runway, executing as lean a glide path as possible while rebuilding our pipeline. At the time, I asked the senior management whether we should persevere or close-up shop - and we chose to persevere. We pulled it off, but lost important staff and momentum - and never fully recovered.
That said, our value proposition was becoming clearer to a range of new partners through an unexpected turn of events: the global rise of Internet shutdowns. Our product set, in developing a cloud-hosted service, a desktop platform, and an Android app - has the infrastructure to design digital services at a very granular level. Using our local app, we could fully localize data collection - enabling users to choose which data to share online and/or internationally (which is what triggers a lot of data protection/compliance law). Europe’s General Data Protection Regulation (GDPR) was coming into effect and there was a growing sense that jurisdiction and sovereignty were going to shape data architecture. And, as a result, I’d expected - in retrospect, too optimistically - for organizations working on digital service extension at the international level to also become interested in architecting those systems in compliance with data law. From my perspective, it is the app/service design equivalent of localization - similar to the way that online hosting services enable users to choose the location of their data center. For most organizations, understanding the relationship between their technology’s data architecture and their legal/political exposure is a change that is, at best, in-process.
Instead, a number of organizations working in politically sensitive environments were experiencing the impacts of Internet shutdowns. While only slightly more than half of the world actively uses the Internet, a growing number of governments have taken to forcing their local infrastructure providers to shutdown connectivity - initially during politically contentious moments, like during violence or elections, but increasingly for extended periods. In approximately 38% of these shutdowns, mobile signal remains on - meaning that it’s possible to use SMS. And Internet shutdowns not only affect intended targets, like human rights activists, election administrators, and political actors, but they also affect a range of vital, mostly unintended targets, like healthcare providers, educators, and basic service delivery. Some of the communities that remembered Frontline as a last-mile, offline communication solution helped us to design product improvements with Internet shutdowns in-mind. That support was clarifying for us - and a welcome return to a community of people who also creatively prioritize serving at-risk populations using technology. By the end of 2019, we’d won a few key, big projects, had a clear roadmap, and were refocusing our sales outreach.
And then, 2020.
In a lot of ways, we were well-positioned to absorb the challenges of 2020 - our team was experienced with remote work, our technology was especially useful in helping public services cope with communicating across the digital divide, and we were successfully diversifying our clientbase. At the same time, our largest client - also for (illegal) reasons beyond our control (and most of theirs) - issued a stop-work order. Our business was resilient enough to absorb it financially, but it was demoralizing and knocked us off our newly recovered course. We took on another extremely difficult client, which consumed most of our attention in the first half of 2021, finally stabilized our runway, and, frankly, burnt me out.
I spent the first half of 2021 exploring options for Frontline as a product, team, market, brand, and group of people served. And, just as in 2018, I brought a menu of credible options to the senior members of the Frontline team, asking which they’d like to pursue. To my surprise, our team decided to shutdown and use our runway to cover the logistics of open sourcing our platform.
So that is what we’re doing.
A few, parting thoughts on our business and market(s):
A lot of our business strategy failed because of my blind spots and naive optimism. I was wrong about the degree of sophistication of most SMS service design, popular interest in SMS automation and service design, and how motivating regulatory frameworks and ethics would be to our target clients. I pushed us to develop, and kill, products based on a very distorted view of how - and how quickly - regulators, our clients, and markets, generally, would evolve. It meant that we were well-positioned when they did (i.e. - we didn’t have to change anything about our business when GDPR took effect), but it also meant that we missed a lot of important opportunities. It’s great to see the growth in investment for public interest tech/digital public infrastructure - and I sincerely hope it grows to provide meaningful governance clarity, operational stability, and resourced, expertise and support guidance for the next generation of builders in this space.
It’s hard to phrase this in a way that won’t sound like sour grapes, but here goes: the business ethics in the humanitarian and social good markets that we’ve encountered have been appalling. The purpose isn’t to shame any particular organization or even complain about the egregious cases - it’s to acknowledge that it’s real, substantially more prevalent than you - yes, you reading this right now - think, and it sucks the soul out of a lot of the most important and inspiring work in the world. It’s hard to know whether the most offensive cases were because the people involved understood the power asymmetry involved, or the cases where they didn’t - but we’ve been extorted, exploited, and technocratically manipulated for political ends, all by public-facing organizations with beneficial tax statuses and social missions.
It is exceptionally valuable to know what kind of technology and business you’re building and why, at a very granular level. Largely because I am genuinely unsure whether it’s possible, or even advisable, to build a technology business that meets everyone’s definition of “good” and the costs of the abstraction can be very high. We provided free, open source software and paid hosted services that targeted last-mile service extension for public and humanitarian organizations - and still, nearly every time we attempted to raise any kind of revenue, we were met with skepticism, if not suspicion. This was true of funders, community, clients, and users through our entire life cycle. All of whom expected that we were also able to set-up turnkey public service design tools, in products that were equally usable by everyone for everything, and that enabled communication in places unserved by infrastructure or institutions. In the same way that an important range of public services are wrestling with building sustainable and “fair” business models - the public interest technology space needs to find a balance between its resentment of revenue, need for stability and sustainability, and the requirements of supporting quality work at scale.
Despite the difficulties involved, I’m here to tell you that there is a growing - and growingly important - opportunity in the technical approach that we took. As long as there are large financial and political interests at stake, there will be value in highly configurable tools, designed for uncertain and unstable infrastructure. The scarier truth is that the markets we tried to serve - disaster response and public services - are more necessary than ever. Whether it’s natural disasters and displacement based on climate change, the increased reliance on remote communications from COVID, or the growing tendency for political turmoil to result in severed Internet connectivity - there’s every reason to believe that we’re going to need more technologies optimized for resilience amidst uncertainty, not fewer. Public interest technology needs more tools that that are responsive to connectivity, focus more on equity of adoption than ease for the designer, and consider distribution at the design stage. And, even more importantly, public interest technology needs people who have done more than build a good platform - it needs people who have done the work to make sure that a platform does good.