Software without coding, documents vs. apps, or the impossible dream of the “personal CRM”

February 19, 2019 · 5 minute read

A couple of years ago, I asked for a recommendation for a “personal CRM” – a client-relationship management tool intended for individual use. As it turns out, I wasn’t the only one asking, and a solution still hasn’t emerged despite outsized interest from the very designers and developers who should be well-poised to create it. Why?

I’ve come to believe that this is because “personal CRM” means something a bit different to each person who asks for it. To my friend Shane, it’d be akin to a proactive virtual assistant, skewing towards the “magical” end of the spectrum. I myself have envisioned a few different products, all which I’ve lazily described using this umbrella term: one for letting me know when I haven’t seen a certain friend in a while, another for applying “tags” to former coworkers, etc. During my current job search, I’ve needed different tools at different times: one centered around colleague outreach to start, but another for tracking interview processes as the’ve continued to progress.

When faced with a moving target and only concerned with meeting one’s own individual needs, we don’t need an “app” or a “product” per se. A document can be structured in a way that meets today’s needs, with the flexibility to easily evolve as requirements change. My “personal CRM” is currently a spreadsheet – I could’ve built a version using Excel or Google Sheets, but I chose Airtable because it stores data in a more structured, database-like format. This lets me build more powerful, customized views on top of my data.

A database. With custom UI sitting on top of it.

This is “an app,” my friends.

Documents vs. apps

From this perspective, Airtable isn’t necessarily a product in-and-of-itself, but a platform that empowers you to build your own products – and it’s far from the only one. Coda, Notion, Quip, Clay, and Actiondesk are also similar in that they’re democratizing software development under the familiar guise of “collaborating on documents.¹” But their document-sheen is only skin-deep:

A creative palette of app-like functionality that you can mix and match

Build something as unique as your team

We took the quintessential parts of apps and turned them into building blocks for your docs

Our goal is to make it much easier to build software

Forget the back and forth with your tech teams. Build powerful automations yourself

Zapier, IFTTT, and Apple’s Shortcuts focus more on integrations and less on data storage and UI, but they’re also key parts of this emerging space – not all software needs a visual user interface². Even Slack – an enterprise chat application on the face of it, has ingrained itself in no small part due to its integrations platform, allowing teams to build mini-products and workflows that suit their own specific needs.

These aren’t necessarily new ideas – Excel macros and Google Sheets scripts³ are less holistic solutions that nonetheless strive to answer the same question: how can we lower the software development barrier to entry?

Apps for small audiences

Part of what made my own CRM so easy to build was the assumption that I’m going to be the only one who ever uses it. Turning it into a consumer-facing product would be a much taller task, but there’s still a ton of value to be captured by software that’s only used by individuals or teams internal to a company.

Shishir Mehrotra, the co-founder and CEO of Coda, highlighted this very point in a piece titled What Will Software Look Like Once Anyone Can Create It?:

We’ll start designing apps for small audiences, not big. Companies will run on their own apps, hundreds of them, tailor-made for every team, project, and meeting. In this world, there’ll be no such thing as an edge case. All the previously underserved teams and individuals will get a perfect-fitting solution without needing to beg an engineer.

Internal applications also have lower user experience expectations than their consumer-facing counterparts, and are simpler for users to authenticate with. And by providing value, they don’t require business models of their own to justify the upfront development cost.

That doesn’t mean that these hurdles can’t be overcome, however – we may be building some consumer applications without code sooner than we know it. A product like Squarespace could shift ever-so-slightly towards app development, or Google’s Firebase could aim for broader consumer appeal. Bubble is one platform purporting to already facilitate this sort of codeless development experience today. At least in some cases, it does seem to be working.

Another approach: instead of using one app-building “platform”, what if the makers of the future study the skills necessary to combine existing applications together themselves, instead of studying computer science fundamentals? MakerPad is one such example of a program and community attempting to educate in this regard:

While such an approach may not suffice in perpetuity, it could mean the difference between bootstrapping yourself to profitability and prematurely taking venture capital in order to hire an engineering team.

What happens to software developers?

As a software developer, should I find this concerning? I admittedly do not, and think that Steven Sinofsky succinctly articulates why by providing some key historical context:

The layers of abstraction that software developers work on top of are continually changing, but there will always be problems to solve despite moving higher and higher up the stack. Most of the platforms covered in this essay already integrate with the popular services of the moment, but developers will always have an advantage insofar as being able to build their own integrations to augment whatever a platform vendor happens to provide out-of-the-box. Understanding databases makes it easier to create a complex Airtable sheet, just as being familiar with loops and conditionals makes you better equipped to craft a complicated workflow in the Shortcuts app. The line between what is and isn’t “programming” really starts to blur.

Similarly, there has always been a gradient between what can be done without code and when you’ll eventually hit a wall with that kind of approach. Adobe Dreamweaver never quite obviated writing your own custom HTML, did it? I don’t personally foresee this ceasing to be the case.

But traditional software development being long for this world isn’t an excuse not to keep up with the changing times. Adobe’s new XD/Airtable integration might be marketed as a prototyping tool today, but how long will it be until those prototypes are good enough for a single designer to ship as production software?

If you don’t like change, you’re going to like irrelevance even less.