Vellum vs. Atticus for Non-Fiction Interior Book Design

Updated October, 2025

If you’ve decided to forgo a book interior designer to layout your book and want to go the self-publishing self-layout route… the options come down to 2.5 real options.

The 0.5 option is using Adobe InDesign which can get you pixel perfect in all the ways, but is also not a tool most self-publishers will ever use.

That leaves us with the two big players in the self-publish space: the legacy contender Vellum and the newish challenger Atticus.

The nice thing about using platform like these is that you can make an edit and then just click a button to get your print ready PDF and ePub file. Compare that with having to have a punctuation-perfect post-edit final manuscript that you send to a designer with any minor change requiring their manual time to make. Which might not happen right away, needs to be schedule, is time consuming, and is also billable.

At the end of the day, they slurp in your manuscript (one way import) and then let you muck around with organizing your content into chapters (and optionally volumes and parts), pick a template, and then export an ePub file for Kindle/ebook and a print ready PDF for your physical paperback and hardcover books.

They both looked wonderful, and they both do an okayish job, but especially for us non-fiction writers, they also both have their shortcomings.

There are plenty of posts showing what they both can do well, and how Atticus is the better choice, that then also include affiliate links to buy Atticus, so… I consider those comparisons pretty biased.

What is generally missing, however, is an overview of what the platforms lack that you might care about, especially as a non-fiction writer.

I’ll break down my areas of concern for us non-fiction authors into a few key areas:

1. Layout Elements Available
2. Layout / Style Options
3. Stability
4. Offline Usability
5. Known Atticus Bugs (Updated October, 2025)
6. Support

Layout Elements Available

Within each chapter, you likely have things like images, bullet lists, sub heads and so on. These are the elements you build your layout with. And generally these import nicely from your Word doc.

Yes, unfortunately the writing industry is committed to Word. It killed me having to export my Google Doc to Word to send to my editor, then try and integrate the changes back into Google Docs, just to turn around and export it again to a Word doc to import it into Vellum and Atticus.

I much prefer how HelpThisBook links to your Google Doc and can “reimport” it anytime. But that platform is for beta reader feedback and not layout. Still, I’d love to see Atticus and Vellum load/sync from a Google Doc.

Once imported, however, Vellum is pretty limited in the elements available. For example, you can have Headings (think H2), but that’s it. Atticus gives you multiple levels of headings from H2 to H6.

But the real deal breaker for me was Callout Boxes. Think like what you put at the end of your non-fiction chapter to give the reader a chapter summary or action items. These are typically formatted differently, often within a box. Atticus has callout boxes. Vellum does not.

So when it comes to the elements available, Atticus is much stronger, and if you need things like levels of subheadings or callout boxes, for example, Vellum simply can’t do it.

Layout / Style Options

Exporting a book in an ebook format – like ePub and/or to Amazon Kindle – in general has pretty limited formatting. Inside the ePub file, it’s just an HTML file with a CSS style file that suggests some formatting. Ultimately, the reader will choose their own font and font size on device. And your content will just reflow based on their preferences.

Think how a reader on their Kindle might zoom their text in bigger or change their font to their preferred font. You don’t have control over any of that. And that’s fine.

You do have some things that matter, like images, chapter heading styling, and such, but nowhere near the complexity that you have with physical books.

When it comes to the layout, though, you want to style how the content looks, from spacing to typography, and so on.

Both platforms offer preset templates to choose from and both let you customize some parts of the layout, but not much.

Vellum offers very little customization. Atticus offers a bit more. But there are plenty of things I’d like to adjust that neither platform allows, like:

• Margin/padding on chapter headers
• How content stays together (in typesetting terms “widows” and “orphans”)
• How the Table of Contents is laid out
• When to show page numbers
• When to include a page number in the table of contents
• How to consistently style the callout boxes
• And so much more

So of the two, Atticus is slightly better, but still lacking.

Stability

Vellum is a native app for your Mac and it works well. It’s stable. It’s fast. It’s everything I’d want.

Atticus, on the other hand, is a “Progressive Web App” (PWA), which means it runs in Chrome and then lets you “install” the web page as an app on your computer, regardless of operating system. That means it runs on Mac, Windows, Linux, etc.

The downside to this, however, is that it’s a webpage. And it’s buggy. And clunky. And slow. And prone to javascript errors. And always trying to “sync” your chapter when all you want to do is view/edit what you already wrote.

This means navigating around Atticus is slow at best, but more so annoying and frustrating. I’ve lost more time waiting for Atticus to load a chapter, respond to clicks, check or uncheck the setting I want to change, and more. It’s painful.

They’ll tell you that you shouldn’t have long chapters, or too many chapters, or too many images, or really anything of consequence. And, even without any of that, it’s just clunky.

If you want to get nerdy, the console loves to fill with errors and warnings from their code. There are known bugs, and support doesn’t actually pass any of that on to their developers. I don’t even think it’s being actively developed anymore.

Some examples:

• When you split a chapter, it leaves behind all kinds of artifacts in the previous chapter, things like empty callout boxes and page breaks, just a whole pile of them at the end of the chapter. Which requires manual cleanup.
• Merging chapters together adds invisible crud that breaks their previewer and you can’t get rid of it without copying the chapter to your clipboard, pasting in plain text, and then going back and reformatting everything from scratch.
• The way they count pages for the print version is buggy and craps out at times. This prevents previewing the print version of the book, and in turn, prevents exporting of the book to PDF.
• Callout boxes at the end of a chapter split across multiple pages, which looks terrible. There’s no way to keep them together. Except for manually adding space. Which will look dumb on Kindle, and is prone to error on print.
• Print versions love to leave a single small hanging sentence at the top of a new page. Or wrap a sentence in undesirable ways, like hyphenating the last word of a sentence so that the next line has a single syllable on it.

Offline Use

Due to the nature of the apps – Vellum being a native app for Mac and Atticus being a glorified webpage – Vellum works wonderfully offline like most native software does.

Atticus, on the other hand, struggles when offline.

For starters, you have to make sure you logged in before you went offline. Otherwise you can’t use Atticus at all.

Then, sometimes, in the middle of writing, for no reason, the app goes to a blank white page. Because it’s offline. This can’t be resolved until you get back online.

So much for writing while offline at a cafe, on a plane, or just with less distractions.

Support

I haven’t had a need to contact Vellum support, so I can’t speak to that.

I have, however, dealt with Atticus support quite a bit. What I found is that they’re not super knowledgeable or helpful or quick. When something is broken – for example their login form didn’t like my email address even though it accepted it when I purchased and setup my login – that can take the better part of a week to resolve.

When the print preview won’t load because their software corrupted their own files, I wasn’t able to export a PDF or preview my book in print. Each round with their support team took 1-3 days round trip and really got nowhere. I was unable to preview or print my book for over a week.

It was a classic “blame the user” because perhaps I pasted something that I shouldn’t have. I did not. Their code is flakey and the app unstable and support unhelpful in resolving actual technical issues.

Their front line support doesn’t know a ton, and mostly ignores what you write in your email, often asking you questions you’ve already provided answers to in the initial inquiry. And they like to offer solutions to problems you didn’t ask about and ignore the questions you do ask.

At best, when they do figure out a bug (after much ado, and you not being able to do things like edit your book, export your print ready PDF, use the editor, etc), they share some generic answer like “Our team is working hard on fixing this, but we don’t have an ETA” or “this is a glitch in the program we are actively working on resolving” and so forth. But… the bugs never get fixed.

Known Atticus Bugs (Updated October, 2025)

Since I wrote this initial post, I ended up shipping my book, Your Business Growth Playbook using files from Atticus. So I now know some of the major hurdles to actually using Atticus in production all the way to the end with Amazon KDP, IngramSpark, Kobo, Apple Books, etc.

Of note, there are a number of bugs to be aware of. Their support team knows about these and so far has not fixed them.

Broken Internal Links

When you use an internal link, for example to link to a chapter from within your text, there are a few issues.

First, the dropdown to choose where to link will show things you can’t link to. For example, if you have a Part (a group of Chapters), it’ll show in the dropdown for an internal link, and it will insert it, but… the link will be invalid.

Second, if you rename a chapter or move it… your internal links will likely break.

Third, if you duplicate your book in Atticus, all the internal links will be broken.

In all three of these cases, Atticus doesn’t produce any error. It doesn’t fix anything. It’ll still happily export an ePub file for you. With broken links.

Amazon KDP will still slurp it in without any error. But when a Kindle user clicks the internal links… they’ll be broken.

IngramSpark, however will reject the ePub file and show you all the broken links. Well, at least the cryptic IDs of the broken links. Good luck figuring out which ones are actually broken and then fixing them.

Low Res Bullet Points

When exporting your print ready PDF from Atticus, certain elements like bullets in bullet lists will be low res pixelated graphics. You don’t have the ability to change these.

When you then import your PDF to IngramSpark, it’ll flag that you have low res images and warn you that when they print, it’ll be pixelated.

Why Atticus uses pixelated low res graphics for bullet points vs. vector or higher res or native font elements is beyond me. But you can’t fix this.

Amazon KDP again will just slurp in the PDF without issue. But when you get your print proofs or printed copies of the book… you’ll see the fuzzy bullet points in print. Which is infuriating.

Orphans and Widows

In typesetting, I learned about two technical terms, Orphans and Widows. These basically refer to dangling text at the start or the end of a page. Think the very last words of a paragraph at the top of a page, or the very start of a paragraph at the bottom of a page.

These don’t look good.

This isn’t an issue for ePub files, but for print layouts… you can’t control these orphans and widows in Atticus. Paragraphs will split where they split and you have to deal with it.

Split Callout Boxes

When using callout boxes in Atticus, for example at the end of a chapter, be aware that they will split across pages in print and you can’t stop that. And it looks terrible.

There’s no way to keep it together.

The one hack you can do is to review the exported print ready PDF and for any callout boxes that split across pages… insert a page split right before the callout box.

The page splits don’t matter in the ePub file, but when you export to a print ready PDF, it’ll force the callout box to the start of the next page. Which means… you’ll have pages with some blank space at the bottom and the callout box at the top of the next page all by itself.

This doesn’t look great. But, it looks better than a split callout box.

And if you dare touch the text or anything else anywhere in your book… review every single callout box in the print ready PDF to make sure nothing has moved on you.

Table of Contents Buggy

The Table of Contents (ToC) in Atticus is buggy. For example, you can choose to Show Subheads in your ToC, but they won’t have page numbers. And you can’t add them.

The hack is to create a Part and then put your sections in the Part as Chapters. Then they can be listed in the ToC with page numbers.

But then… if you turn off Show Subheads… the headings in your Chapters in your Parts still show up. Even though you don’t want them to.

To make matters worse, in the editor, when you preview the ToC, it’ll look correct. But when you use the previewer for either digital or print… the darn subheads will show up. Even with the option turned off.

I’ve toggled the setting on and off. I’ve restarted the app. I’ve cleared the cache. I’ve hard refreshed the app to the latest version. It doesn’t matter. And support sees the issue, too.

The hack is to change your subheads (like H2) to H3. And in your style editor, change H3 to look like H2. And then if you use H3 anywhere… make those H4. It’s super hacky. And a terrible way to organize your content.

And then, back in the editor, even though you’ve changed the style of H3 to look like H2, they’ll still look like H3s…

And now, in the ePub file… your headings will be incorrect…

In summary, there are 3 Table of Content bugs in Atticus here that need addressing:

1. Subheads should print page numbers in ToC (or at least have a checkbox option for that).
2. If I have Parts, and ask not to print Subheads, they shouldn’t be printed in the ToC.
3. If I change heading styles in my Formatting tab, that should be reflected in the editor, at least the sizing.

Bottom Line

I’m not putting prices in here, as I often see pricing being used as a reason to go with Atticus. If you’re looking to save a few bucks, you’re choosing a platform for the wrong reasons. Pick the one that does what you need. Which… for us non-fiction authors, is kinda neither of them.

In the end, I like Vellum, except for the lack of required callout boxes, subheads, and layout/style options.

I’m stuck with Atticus, despite it’s bugginess, quirks, slowness, and instability.

Here’s how they compared in what mattered for me from one to five asterisks with one (*) being the worst and five (*****) being the best.

	Vellum	Atticus
Platforms	Mac Only	Mac, PC, Linx, etc
Elements	**	***
Layout	**	***
Stability	*****	**
Offline	*****	*
Support	n/a	*

Next time, perhaps I’ll suck it up and go with InDesign – or, better yet, just hire a book interior designer.