The context
Dissertation Editor helps PhD candidates and academics get their most important work across the finish line — and it does it with 100% human editing, a promise central to the brand. Behind that promise is a genuinely complex operation: a workforce of ~40 editors and statisticians, matched to projects that vary enormously in scope — word and reference counts, formatting standards, rush timelines, and multi-stage editing and proofreading.
The business didn’t have a problem with its records. It ran on Pipedrive, and it ran on it seriously — a deal model customized with 86 fields. What it lacked was the operational layer on top: the connective tissue that turns a CRM record into a quote, a scheduled consultation, an assigned editor with the right files, a delivered project, and a paid invoice.
The challenge
- No home base for editors — assignments, guidelines, source documents, due dates, and status were scattered across email and shared drives.
- Manual quoting and booking — turning a client’s document into a consistent quote, and scheduling consultations, was hands-on and easy to get wrong.
- An unusual, stage-heavy workflow — some project stages matter to editors, others are purely internal (payment, QC, returns). Any system had to know the difference.
- A hard constraint: augment, don’t replace. The team depended on Pipedrive and its 86-field model. The right move was to build around it, not migrate off it.
- The brand promise had to hold — all editing is human. Automation could touch everything around the work, but never the editing itself.
The approach
I build operational software on top of the tools a business already owns rather than replacing them — and Dissertation Editor is a textbook example. I treated Pipedrive as the system of record and built the operations platform around it: client-facing intake and scheduling, an editor portal, an admin dashboard, and a synchronization layer that keeps it all in step with the CRM. I shipped a working production version in about two weeks, then hardened and expanded it continuously.
A word on how one person delivers something this complete: I run teams of AI agents to handle execution — generating test plans that exercise every path through a flow, running them, and iterating until behavior is genuinely solid (the platform carries 100+ automated end-to-end tests) — and to produce the documentation. I make the judgment calls: how to model the stage logic, where the source of truth lives, how to get auth, scheduling math, and email deliverability right. To be clear, that’s how the software was built — the editing Dissertation Editor sells is entirely human. I automated everything around it.
What I built
Client intake with instant, automated quoting.
A client uploads their document; the platform analyzes its structure — word count, pages, references, figures, tables, front matter — and returns an itemized quote from a maintained rate schedule, across service types like line editing, copy editing, proofreading, and formatting. A calibration harness continuously checks quote accuracy against known-good examples.
Consultation scheduling and video.
Editors publish availability; clients book against it; the system generates Google Meet links and calendar invites, sends automated 24-hour and 1-hour reminders, and enforces sensible booking rules — with a “send booking invite” flow that logs the client straight in via a secure link.
An editor portal — the workforce’s home base.
Passwordless magic-link sign-in, a “My Projects” board showing exactly the work that’s theirs and active, per-project files and instructions, a job board where editors express interest or are assigned, two-way messaging with admins, and self-service payroll.
An admin dashboard.
An assignment board, editor and group management, rate configuration, QC review, payroll oversight, and a “portal preview” that lets an admin see the platform exactly as any editor or client sees it.
A job-board engine synced from the CRM.
When a deal changes stage in Pipedrive, a webhook flows the relevant fields into the platform’s own store. Internal codes are resolved to human-readable labels, and the engine is stage-aware — it knows which stages are active editor work versus internal back-office states, so a board only ever shows what’s genuinely on an editor’s plate.
Reliable, brand-aware email.
All transactional email runs on Amazon SES with full deliverability configuration (DKIM, custom send domain, DMARC), automatic bounce suppression, and one-click unsubscribe.
The hard problems
Anyone can wire up a form. The value is in the details that make a system trustworthy in daily production:
- Turning an 86-field CRM into a clean, safe job board — selective mapping, code resolution, and strict rules so internal data (including pricing) never leaks to editors.
- Getting the source of truth right — the portal reads from its own store rather than calling Pipedrive live, keeping it fast, resilient, and decoupled from CRM hiccups.
- Idempotency under webhook retries — CRM webhooks fire more than once; the system guarantees a client never gets a duplicate invitation and actions never double-apply.
- Timezone- and DST-correct scheduling — availability, bookings, and reminders are computed with real timezone rules, so reminders fire at the right moment for everyone.
- Two brands, one platform — extended to power a second, UK-facing brand, with client experiences and emails fully brand-switched while the shared editor workforce stays on one portal.
- Run in the client’s own cloud — deployed and operated in Dissertation Editor’s own AWS account, with point-in-time recovery and staged, backward-compatible deploys.
Results
- Live in production, used daily by the core team and ~40 editors and statisticians.
- First production version shipped in about two weeks, then evolved continuously across roughly 300 releases.
- Editors now self-serve their entire pipeline — active work, files, schedule, messages, and pay — instead of chasing details across email and spreadsheets.
- The platform scaled to a second brand (a UK-facing sister service) on the same foundation.
- The team kept the CRM they rely on and gained the operational platform it was missing.
What this shows
Dissertation Editor is a fair measure of what I do: take a genuinely unusual business, build the operational platform it’s missing on top of the tools it already trusts, and get it into production — tested, documented, and reliable — fast enough and lean enough that a company this size can afford enterprise-grade delivery. And then keep evolving it, all the way to a second brand.