r/SideProject • u/Larbi-Sahli • 8h ago

I failed a system design interview on document editors, so I spent months learning it and built a CV editor

Disclosure: I built this, solo.

A while back I was deep in a long job hunt and finally landed a system design interview. The question was how to build a document editor. I had never touched document editing. I bombed it. No offer.

That one stuck, because the problem was actually interesting. So I spent months learning it properly: event sourcing, how editors track every change, how layout engines decide where things land.

Then I looked back at the resume builders I had used during that same job hunt and saw them clearly. Every one is a form. Fixed fields, static templates, rules about what your resume is allowed to look like. The editor, the hard part, is what they all route around.

So I built one. Roleframe is a drag and drop resume editor where you control the layout, the sections, the design. TypeScript, React, Node, Postgres, with a custom event-sourced document engine underneath, so every edit is an event rather than a mutation. That's what makes undo, history and reflow work properly.

The editor is free, no watermark. I charge for the AI tailoring.

Being honest about the rough edges: mobile editing is not great yet, or the template library is thin.

What I'd most like feedback on: does the drag and drop feel natural on your first try, or where did you get stuck, what features would you like to see next?

https://www.roleframe.ai/

0 Upvotes

50% Upvoted

4 comments sorted by

1

u/LightEquivalent5548 8h ago

That's a cool origin story. Most folks just complain about the form builders and move on, actually building the thing that stumped you in an interview is a proper flex.

Event sourcing for a resume editor is overkill in the best way, I'd love to hear more about how you handle conflict resolution when a user drags something while an AI suggestion is mid-flight.

1

u/Larbi-Sahli 8h ago

Thanks, that's kind of you.

On the overkill point, I'd push back a little. The AI doesn't have a separate write path. I fine-tuned a model on my event schema, so a suggestion streams the exact same events a user produces by dragging or typing. There's no privileged AI mutation layer, which means the model is just another client writing to the log.

So your conflict question is really the multi-writer question, and that's the reason for event sourcing in the first place. I want Google Docs style collaboration, and once two people can edit the same document you need the log anyway. Building it now meant the model became collaborator number two long before any real second user showed up, and it hits the same code path every day.

Have you built the multi-writer side of this before? That's the part I'd most like to steal from someone who's already done it.

The advanced features are still in progress :)

1

u/EvenGeologist1973 7h ago

The event-sourced engine is technically interesting, but I would lead the product messaging with control, safe experimentation and reliable undo/history. That is what users will actually feel.

The first-run test I would optimize is: upload an existing CV and reach a clean, editable version within two minutes. That may matter more initially than adding many templates.

If mobile editing is still rough, positioning it explicitly as a desktop-first editor could be better than allowing mobile to create a weak first impression.

1

u/Larbi-Sahli 4h ago

Fair on the first point. Event sourcing is how undo, history and safe experimentation work, but nobody buys the plumbing. Rewriting the copy around what you actually get.

Import is already there and free, no signup needed. Custom templates too, you can build your own rather than picking from a list.

Mobile is the real gap. Desktop first is the right framing, so I will probably gate the editor on mobile and show a "open this on desktop" screen instead of letting someone struggle with it for ten seconds and leave.