How to eat an elephant: Lessons on building a software platform

Two years ago, Cam and I joined KC with the crazy idea of helping an agency evolve into a software company. Fast forward to the present and KC is bigger and stronger than we ever predicted.

Alongside that, I’ve got more kids, more belly and less hair than I ever predicted too. However I’ve learnt a hell of a lot of lessons about building our platform, Communiqué, from the ground up – here are a few of them.

UX is hard; it’s more than looking good, be strict

Everyone thinks they know what looks good, everyone secretly thinks they get design. Well they don’t, because it’s bloody hard and there’s so much more to it than making a screen look good.

We get a lot of compliments about our design, but I find things in Communiqué (CQ) that make me cringe every single day. We do have a great design and it’s because we have a designer who understands aesthetics and experience. Where we struggle is 100% consistency across the entire UI.

With so many screens, and moving with such speed, it’s often very difficult to enforce all our design mandates. Whenever we don’t think we don’t have time and bypass design for a new screen, the results speak for themselves.

Oh, and we’ve also learnt that different designers working independently on different areas of the platform = bad. Every time.

Be forceful about user input

Building software in KC is my small team’s day job. For everyone else, it’s a part-time thing, or a spare-time thing. Or a no-time thing. No matter how important CQ is to KC, most of my colleagues have clients and writers to keep happy. As a result, it can be hard to get their time and attention. But it’s vital. If the requirements for our software are determined by a bunch of coders and data nerds, the end result will be similar to that car Homer designed in the Simpsons. Our platform works because it’s a result of ideas that have been squeezed out of content marketers. Only on rare occasion, violently.

Don’t build what you don’t have to

I’ve spent many years as a software consultant wrangling, wrestling and pleading with enterprise software to make it do what the customer needs. Now that we’re building our own, the urge is strong to build everything we need ourselves. That’s the way to make it work perfectly, right? No; these days, that’s insanity. For the same reasons that KC is able to build software, there are countless tools being released all the time that do one thing, very well. And of course everyone’s got an API. There’s absolutely no need to send your own email notifications, or write your own performance monitoring, or even handle your own helpdesk.

Offshore development is about trust, and not all about cost

I’ve been involved in a lot of offshore projects, with mixed results. This time we’ve got it right and it’s because we’ve found leaders we trust and let them fill the team with people they trust. Our team in Trivandrum in India is a lot cheaper than a similar team in Australia, of course. But what wasn’t immediately obvious to me, is that I couldn’t have built this team in Australia with pretty much any budget. The talent pool in places like Trivandrum is just amazing. Whenever we need additional developers with our exact skill set, we have them in two weeks. All set up, fully briefed on the project, ready to code. To find these quality developers in Australia willing to work at a small marketing agency wouldn’t be possible in a year.

Everyone wants something different

Over the course of a week I’ll have requests for new features and fixes coming from our editorial team, our social team, our native advertising team, our client managers and, of course, the dreaded sales guys (sorry, Cam). Everyone has a different perspective and everyone wants something different in our platform. On a bad day I’ll close my eyes, put my fingers in my ears and start wailing. On a good day I’ll use my juggling skills and work with stakeholders to agree on a set of priorities that can be understood by everyone. It’s impossible to give everyone what they want (and if we tried, we’d end up with software that does nothing well), but it is possible to define a vision for the product and make sure everyone understands it. Once people understand the direction we’re heading in, and why, they can usually live with their request sitting sadly at the bottom of a long dev queue for a while.

The best way to eat an elephant

Is one bite at a time. Yeah yeah, agile, iterative, short sprints, MVP and so on.

Yep, got it, everyone knows they have to be agile. No arguments here. But this is the first time I’ve been part of a business where it’s agility or death. Content marketing is moving so fast that we can’t afford to spend too much time on any single large piece of functionality. And our business users and clients just don’t have much time to give us. This leaves us with a single option, to build small pieces of functionality and see whose boat it floats.

If it’s no-one’s we move on, if it’s a hit, we’re already halfway through phase 2 and starting to plan phase 3.

Building software at pace is not easy, but it is thrilling and has been very rewarding. Learning lessons the hard way is all part of this thrill, and I don’t see it letting up. When the lessons stop, it’s time to worry.