Build the software that powers publishing, literacy and the dissemination of knowledge.

Our business.

We started about twelve years ago, with a system built to meet the needs of a single publisher, and initially grew by working mostly with trade publishers. More recently we have gained a strong customer base of academic and professional publishers, who tend to need management of much more complex data.

Our clients’ users work in editorial, production, marketing, and sales departments of book publishers, and our aim is to let them all work together as a single team. The book publishing domain is very complex, requiring a well structured and complex back end and a well-crafted user interface.

This is not a VC-ish operation, and client fit is much more important to us than taking on new clients for the sake of monthly numbers.

We’ve bootstrapped ourselves to profit, have solid cash reserves, and think of ourselves as a small and stable business offering expertise to our specialist clients. Our client retention and industry reputation are both excellent.

What we care about.

We are advocates of technical literacy in publishing, particularly for junior publishing staff, which leads us to initiatives such as running a Day of Code to empower publishing staff, running Side Project Summer, connecting the worlds of tech and writing with justsimply.dev, and making the silly yet pointed nope.business. Our corporate charity is also one of our clients: the literacy charity BookDash.org. We have two sister book publisher companies, Snowbooks and Make Our Book, and we are an active member of the Ruby community, including publishing an edition of _why’s Poignant Guide for the Brighton Ruby 2020 conf.

Our brand promise is to make publishers better by sharing our expertise, and we communicate our expertise at scale through our app, and through writing and speaking.

Our technologies.

Consonance.app is a conventional Ruby on Rails (currently version 7x) monolith, which allowed us to rapidly develop to cover a lot of functionality.

Now we’re migrating some complex interface requirements to React, with a GraphQL API to also allow clients to develop their own integrations, and others to HTML-over-the-wire using Turbo. We’ve been so delighted with the imaginative, brilliant things some of our clients are building with their own data and like the idea of Consonance being “The Most Open Publishing Software”. Here’s more about Consonance’s stack:

• 500+ models. It’s a complex business domain.
• One main shared application, some single-client deployments.
• All hosted happily on Heroku. There’s a lot of scaling possible before we would ever have to look elsewhere and we like outsourcing a lot of our ops to Heroku.
• PostgreSQL. We solve a lot of performance problems with the advanced SQL skills we have in the team.
• AWS: RDS, S3, SES, SQS, a little Lambda.
• The existing interface is mostly ERB, with some React, mounted by Stimulus.
• Some complex interface areas migrated to React (currently on React 17x).
• Most other interface areas migrating to Turbo.
• GraphQL API for React and client integrations, with Apollo client.
• RSpec, Cucumber, React Testing Library and Jest.
• GitHub, including Actions and Dependabot.

Slack for chat, voice and video calls. Basecamp, VSCode, Skylight, Git Kraken, and Freshdesk. The vast majority of our work is on the app with maybe ~10% on implementations and integrations.

Our team.

We’ve been a team of four or five for the past few years, with a pretty even gender and age balance and a tendency towards full-stack skills.

Two of the three founders work full-time as programmers and business managers and we aim for a collaborative approach.

All staff are full time employees, and we work as a distributed team across the UK. We dropped office life at the beginning of the pandemic, and it’s worked well for us, so we no longer have an office at all. We rarely meet up, at industry events.

On a daily basis, we put a “stand-up” onto Basecamp first thing in the morning, have midday meetups on Slack, and collaborate for advice and pair programming as needed.

As a team, we:

• share our thoughts on design and approach to get clarity and avoid surprises at PR stage, which should be constructive, knowledge-sharing and positive
• take inputs and ideas from others, with direction decided by the technical directors
• update each other regularly on progress
• prioritise delivery over perfection
• prioritise maintainability

We work a four day week (Monday to Thursday), without overtime or out-of-hours pager duty, which is covered by the directors. We’re flexible on hours - 7.5 working hours a day.

We aim for calm and steady working practices, achieved through things such as de-emphasising delivery dates, very rare meetings, only supporting the latest browser versions, no formal backlog, only building a web app not a mobile app, only hosting on Heroku, minimising custom developments and custom integrations, and being flexible if work and life clash from time to time.