Building a Social Reading App From Scratch
Industry
SaaS Startup
Company size
1 - 10 Employees
About
Jotter (formerly known as Unbound) is a modern social publishing platform and app designed for both writers and readers. It aims to democratize the literary world by removing the gatekeepers of traditional publishing, allowing anyone to easily share full-length novels, short stories, memoirs, and essays with a global community.
The Situation
Jotter is a social reading app. The concept sits at the intersection of consumer behaviour and community — a space where product-market fit is everything, and the difference between an app people use once and one that becomes a habit is usually decided in the first few weeks after launch.
The founding team had a clear vision for what Jotter should do: give readers a place to track what they are reading, share reactions, and connect with others around books. The market thesis was solid. The founding team had domain expertise and strong instincts about what readers actually want.
What they did not have was in-house technical capability.
Every decision — stack selection, architecture, build-vs-buy tradeoffs, scope prioritisation — required a trusted technical partner, not just a vendor who would execute whatever they asked for. The risk was not writing bad code. The risk was building the wrong things, in the wrong order, and arriving at launch with a product that was technically complete but commercially irrelevant.
The structural problem: early-stage consumer apps fail most often not because the idea was wrong, but because the build expanded beyond what the market needed to see first. Features that feel essential at the whiteboard stage delay the moment when real users tell you what is actually essential.
Key Result Metric: A working product, used by paying customers, within the engagement timeline — not a feature backlog delivered on time.
Why they called us
Jotter came to Halcrow needing a technical co-founder’s equivalent: a team that could translate a product vision into working software while the founding team focused on sales, customer discovery, and fundraising.
This was not a typical agency brief. It required a team that could make technical decisions with commercial awareness — who understood that every week of build time was a week before the product was in front of users, and that users are the only reliable source of product truth.
Law 3: Scope is a delivery variable, not a wish list. The founding team had a long list of features they wanted. Halcrow’s first job was to identify the shortest path to a product worth testing — and hold that line throughout the build.
How we worked
Embedded Build: From Vision to Live Product
The operating model treated Halcrow as the technical function of the business during the build period.
Architecture and stack decisions: the app needed to be fast to build and fast to iterate. Stack selection was driven by those constraints — not by technical preference or résumé optimisation. Decisions were made with the founding team, explained in plain terms, and documented so nothing was locked inside anyone’s head.
Scope management: this was where the embedded model earned its value. Founding teams building consumer products for the first time tend toward maximalism — one more feature, one more integration, one more edge case handled. Each addition feels low-cost in isolation. Collectively, they push launch months further out.
Halcrow’s role was to hold the scope boundary: not because features are bad, but because an app that launches in four months with five things that work beats an app that launches in twelve months with fifteen things that almost work.
Law 5: Delayed decisions are the most expensive decisions. Every feature deferred to post-launch can be validated with real user data before it is built. Every feature built before launch is a bet placed without evidence.
Incentive alignment: the engagement was structured with a delivery bonus tied to the product being used by paying customers — not to features shipped. That incentive shaped decisions throughout. It meant Halcrow had skin in the same game as the founders.
Phase 1: Core Reading Experience
The first phase focused on the product’s essential loop: adding a book, tracking reading progress, leaving reactions and notes. No social layer yet. The goal was to validate that the core mechanics felt right before building the features that depend on other users being present.
Phase 2: Social Layer
With the reading core stable, the social features were introduced: following other readers, seeing what friends were reading, sharing reactions publicly. This sequencing mattered — social features built on an unreliable core create compounding UX problems.
Phase 3: Launch Readiness
Pre-launch work covered app store submission, onboarding flow, and the basic analytics instrumentation needed to understand user behaviour from day one. Jotter launched with a product their first users could genuinely use — not a demo.
WHAT CHANGED
Jotter went from a vision on a whiteboard to a live product with paying customers. The founding team, who came in with strong product instincts and no technical capability, left the engagement with a working app, documented architecture, and a clear picture of what the next iteration needed to address.
The handover was structured: codebase, documentation, and operational knowledge transferred cleanly.
WHY THIS WORKED
Consumer apps do not fail because the technology is hard. They fail because the build expands, launch slips, and the founding team runs out of runway before they have learned anything from real users.
The Jotter engagement worked because scope discipline was non-negotiable from day one. The founding team could articulate exactly what Jotter needed to do to be worth testing — and Halcrow built that, not more.
Law 9: The constraint is usually organisational, not technical. Building a social app is technically straightforward. Building the right version of it, in the right order, with a team that has no prior experience managing a technical build — that is the hard problem. That is what the embedded model is designed to solve.