DEV Community: letx app

How to Write a Research Paper With Co-Authors in 6 Steps

letx app — Thu, 29 Oct 2026 14:00:00 +0000

Writing a paper with co-authors fails in predictable ways. Someone overwrites someone else's paragraph. Nobody knows which version is current. Two people use different notation. Then the last week turns into a scramble.

These six steps prevent most of that. They work in any editor, and I use LaTeX in the examples.

Step 1: Agree on the outline and the owners

Before anyone writes a sentence, agree on two things.

The outline: the section headings and a one-line goal for each section.
The owners: one person responsible for each section.

An owner is not the only person who may edit a section. An owner is the person who decides what goes in it and who resolves disagreements. Everyone else suggests changes through comments.

A table in a shared note is enough:

Section	Owner	First draft due
Abstract	Sam	Week 5
Introduction	Sam	Week 3
Method	Priya	Week 2
Experiments	Lee	Week 3

Step 2: Give every section its own file

One giant main.tex causes most edit collisions. Split the paper so main.tex only assembles the pieces:

% main.tex
\documentclass{article}
\input{macros}

\begin{document}
\input{sections/abstract}
\input{sections/intro}
\input{sections/method}
\input{sections/experiments}
\input{sections/conclusion}

\bibliographystyle{plain}
\bibliography{refs}
\end{document}

Now two people can work on method.tex and experiments.tex without touching the same lines.

Step 3: Keep notation in one `macros.tex`

Put every shared symbol in one file, and make one rule: nobody defines a macro inside a section file. This stops the same vector appearing in three different styles. I wrote this up in Stop Notation Drift in Co-Authored LaTeX Papers With One macros.tex.

Step 4: Give every author a comment command

Comments like % TODO fix this get lost. Give each author a color and a command, plus one switch that hides everything for the final build:

% in macros.tex
\usepackage{xcolor}
\newif\ifcomments
\commentstrue   % use \commentsfalse for the submission build

\newcommand{\authnote}[3]{\ifcomments{\color{#2}[#1: #3]}\fi}
\newcommand{\sm}[1]{\authnote{SM}{red}{#1}}
\newcommand{\pr}[1]{\authnote{PR}{blue}{#1}}

In the text:

We evaluate on three benchmarks. \pr{Is the third one's licence cleared?}

Notes appear in the PDF while drafting, and one line removes all of them before submission. Search the project for \sm{ and \pr{ at the end to catch strays.

Step 5: Snapshot before every big rewrite

Large rewrites are where work gets lost. Before anyone restructures a section, save a version you can return to. That can be a Git commit, a named version in your editor, or a copy of the folder. Name it by intent, like "before restructuring experiments", not "v12".

Check how much history your tool keeps before deadline week. Some free plans keep a limited number of versions or a short time window.

Step 6: Freeze one week before the deadline

The final week is where organized teams fall apart. A simple schedule helps:

Day -7: Content freeze. Fixes only, no new claims or experiments.
Day -5: One person resolves all comments and switches \commentsfalse.
Day -3: Build the final PDF and check the page limit. Fix length with layout changes, not last-minute cuts to results.
Day -2: Everyone reads the compiled PDF, not the source. Look for ?? references, overfull boxes and incomplete bibliography entries.
Day -1: Upload to the submission system and test the upload.

Reading the PDF matters more than it sounds. The source hides problems that a reader sees in seconds.

Picking a tool for these steps

These steps work with email and Git, but they are easier when everyone edits the same project live. With a live editor, there is no "which version is current" problem, and a one-file-per-section structure keeps edits from stepping on each other.

If you want to try it, LetX is a collaborative LaTeX editor with unlimited collaborators on its free plan (it caps free compiles at 40 per day). You can import an existing project as a ZIP and invite co-authors with a link. I work on it, so see yesterday's post for how it compares with Overleaf and test it on a real paper before committing.

A checklist to copy

[ ] Outline and owners agreed before writing
[ ] One file per section
[ ] One shared macros.tex
[ ] One comment command per author, with a switch to hide them
[ ] A named snapshot before every big rewrite
[ ] A content freeze one week out
[ ] Everyone reads the compiled PDF before submission

Which step does your team skip? Tell me in the comments. Tomorrow: fixing LaTeX compile errors with an AI assistant.

LetX vs Overleaf: A Free Overleaf Alternative With Unlimited Collaborators

letx app — Wed, 28 Oct 2026 14:00:00 +0000

If you are searching for an Overleaf alternative, you are probably in one of three situations. You have a paper with three or more authors and hit the free plan's collaborator limit. You lost version history you needed. Or you are paying per seat for a lab and the total looks high.

This post compares the two tools on the nine points from yesterday's checklist. I work on LetX, so I am biased, and I have tried to say where Overleaf is the better choice. All numbers below come from each vendor's own pages as I read them on 26 October 2026. Plans change, so check both pricing pages before you decide.

The short version

Use LetX if you write in teams of three or more, want unlimited collaborators on a free plan, and care about compile speed.
Use Overleaf if you work alone or with one co-author, need its paid features like track changes, or your institution already provides it.
Use neither if your team is happy in a local setup with Git and has the skills to maintain it.

Free plans side by side

	Overleaf Free	LetX Free
Collaborators per project	One collaborator	Unlimited
Projects	Not stated on the plans page	Unlimited
Compiles	Limited by compile timeout	40 per day, builds up to 2 minutes
Version history	Previous 24 hours	Last 15 versions
Templates	Included	All 1000+ included
AI assistant	5 uses per day on the plans page	Lexi is a Pro feature
Price	$0	$0

Two things stand out. LetX's free plan has no collaborator cap but does cap compiles at 40 per day. Overleaf's free plan caps collaborators but, as far as the plans page states, does not give a daily compile count. If your team compiles constantly, the 40-per-day limit is the number to watch.

Paid plans side by side

	Overleaf	LetX
Student / academic	$8.25 per month billed yearly ($13 monthly), 10 collaborators per project	Academic Pro $9 per month or $90 per year, unlimited collaborators
Mid tier	Standard, $16.75 per month billed yearly ($25 monthly), 10 collaborators	n/a
Top tier	Pro, $33.25 per month billed yearly ($45 monthly), unlimited collaborators, SSO and admin features	Pro $18 per month or $180 per year, unlimited collaborators
Unlimited compiles	Paid plans extend the compile timeout	Included in Pro and Academic Pro
Full version history	Paid plans	Pro and Academic Pro
GitHub integration	Paid plans (integrations)	Pro and Academic Pro

A few notes on reading this table fairly:

Overleaf's student plan requires enrollment at a degree-granting institution. LetX's academic plan covers students, faculty and university staff, and verification asks for a transcript or ID document.
LetX's Academic Pro includes everything in Pro except that its monthly Lexi AI allowance is smaller.
Overleaf's higher tiers add things like SSO and audit logging that matter to institutions. Compare against what your department needs, not against the headline price.

Where each one wins

Overleaf is strong when:

You work alone or with one co-author, so the collaborator cap never bites.
You need track changes or its other paid review features.
Your university already pays for it, which makes the price irrelevant.
You want the largest existing ecosystem of tutorials and community answers.

LetX is strong when:

Your paper has three or more authors and you do not want to pay just to add a collaborator.
You want live editing on a CRDT (Yjs), which merges simultaneous edits instead of locking or conflicting.
You want a free plan that includes the whole template library.
You want an AI assistant that reads the project and the compile log (Lexi, on Pro). I cover it in a later post.

Switching takes about two minutes

You do not need to commit before you try it:

In Overleaf, download your project as source (the ZIP).
In LetX, create a project by uploading that ZIP.
Compile and check that images, .bib files and folder structure came across.
Invite a co-author and edit the same section at the same time.

LetX runs standard TeX Live, so most projects compile without changes. If something does not, check packages and engine settings first.

What I would test before switching

Your slowest document. Compile the longest paper or thesis you have and compare times on both tools.
A real co-author conflict. Two people, one paragraph, at the same time.
The deadline scenario. Count how many compiles you actually do in a day. If it is near 40, price Pro in.

For the full list of claims and caveats, I keep a LetX vs Overleaf comparison page, and a longer post on Overleaf's free plan limits. Try it free at letx.app.

If you have switched in either direction, I would like to hear what surprised you. Tomorrow: how to write a paper with co-authors in six steps.

How to Choose a Collaborative Research Writing Tool: A 9-Point Checklist

letx app — Tue, 27 Oct 2026 14:00:00 +0000

Most teams choose their research writing tool the week a paper is due, which is the worst possible time to find out it cannot do what you need.

A tool that is fine for one author can fall apart with four. A free plan that looks generous can stop you the night before submission. A tool that is easy to start with can be hard to leave.

This checklist gives you nine questions to ask about any collaborative research writing tool, including LaTeX editors, Git setups, and word processors. Run your shortlist through it before you commit a paper to one.

The 9-point checklist

1. How does it handle two people editing at once?

There are only a few answers: the file is locked, you merge afterward, or edits combine live. Live editing is the most comfortable for prose, but test it with a real conflict. Ask two people to edit the same paragraph at the same time and see what happens.

2. What does the free plan limit?

This is where surprises hide. Check these before the deadline, not during it:

How many collaborators can join a project?
How many projects can you have?
Is there a daily or monthly compile limit?
How long can a single build run before it times out?

A tool that limits collaborators on its free plan is a poor fit for a paper with three or more authors, unless you plan to pay.

3. How fast and reliable is compiling?

If you write in LaTeX, the edit-compile-preview loop is where you spend your time. Time a full build of your actual paper, not a demo. Check what happens with a long document, many figures, or heavy TikZ.

4. How much version history do you get?

History is your safety net for big rewrites and for the moment a co-author deletes a section. Find out how far back it goes and whether you can restore a single file or only the whole project. Some plans keep only a short window, and some keep a limited number of versions.

5. Does it have the templates your venue needs?

Look for the specific class your target venue uses, such as IEEE, ACM, Springer, or your university's thesis template. Starting from a working template saves hours of preamble debugging.

6. What happens to your unpublished work?

Unpublished results are sensitive. Look for a clear statement about who can see your projects, where they are stored, and whether your documents are used to train AI models. If the answer is vague, treat that as an answer.

7. Can you leave?

Portability protects you. You should be able to export a plain ZIP of your source files at any time and open it in any other LaTeX setup. Also check that you can import an existing project, so switching in is not a rewrite.

8. How does review and feedback work?

Co-authors and advisors need to comment without rewriting. Find out whether the tool has comments or tracked changes, or whether your team will rely on a convention instead, such as per-author comment macros. If the tool has no built-in review feature, you can still make one with a small amount of structure.

9. What does it cost at your team's size, over the whole project?

Price per person adds up for a lab, and student prices can have eligibility rules. Work out the total for the people you actually have, for the months the project will run, and compare that with the features you will use.

A scorecard you can copy

Score each tool from 0 to 2 on each point (0 = fails, 1 = partial, 2 = solid). Weight the rows that matter most for your team.

#	Criterion	Tool A	Tool B	Tool C
1	Simultaneous editing
2	Free-plan limits
3	Compile speed and limits
4	Version history
5	Venue templates
6	Privacy and AI policy
7	Import and export
8	Review and feedback
9	Total cost for your team

A total matters less than any zero. A zero on a point your team depends on is a reason to rule a tool out.

Run it on a real project

Do not judge a tool from its homepage. Take a real paper, invite your actual co-authors, and spend one afternoon doing this:

Import your existing project.
Have two people edit the same section at the same time.
Compile the full paper and note the time.
Roll back to an older version.
Export a ZIP and open it somewhere else.

If a tool survives that afternoon, it will probably survive your deadline.

Where LetX fits

I work on LetX, a collaborative LaTeX editor, so weigh this part accordingly. Here is how it answers the checklist, based on what is published on the site:

Collaboration (1, 2): Live editing built on Yjs, with unlimited collaborators and unlimited projects on the free plan.
Limits (2, 3): The free plan allows 40 compiles per day and builds of up to 2 minutes. Pro removes the daily cap and allows 5-minute builds.
History (4): The free plan keeps the last 15 versions. Full history is on Pro.
Templates (5): 1000+ templates, including IEEE, ACM, Springer and Elsevier journal formats and many university theses. Browse the template library.
Privacy (6): Projects are private by default, and LetX states that documents are never used to train AI models.
Portability (7): Import any ZIP, including Overleaf exports.

On review and feedback (8), check the current feature set yourself, and use the comment-macro approach from my earlier post on shared notation if you need a lightweight system. Limits and prices change, so confirm them on the pricing page before you decide.

Your turn

Which of the nine points has bitten your team before? Tell me in the comments. Tomorrow I will compare LetX and Overleaf head to head against this same checklist.

Stop Notation Drift in Co-Authored LaTeX Papers With One macros.tex

letx app — Mon, 26 Oct 2026 09:28:27 +0000

Open a paper with three authors and read the math sections in order. There is a good chance the same vector shows up as \mathbf{x}, \vec{x}, and plain x, and that \argmin is defined twice with slightly different spacing.

Nobody planned it. Each author wrote their own section, defined what they needed, and moved on. The reviewer is the first person to read the whole paper in one sitting, and notation drift is exactly what they notice.

The fix takes about five minutes and works in any editor.

Put every shared symbol in one file

Create a macros.tex next to main.tex and load it once in the preamble:

% main.tex
\documentclass{article}
\input{macros}

\begin{document}
\input{sections/method}
\input{sections/experiments}
\end{document}

% macros.tex
\usepackage{amsmath, amssymb}

% Vectors and matrices
\newcommand{\vect}[1]{\mathbf{#1}}
\newcommand{\mat}[1]{\mathbf{#1}}

% Operators (the * lets subscripts sit under the operator in display math)
\DeclareMathOperator*{\argmin}{arg\,min}
\DeclareMathOperator*{\argmax}{arg\,max}

% Sets and expectation
\newcommand{\R}{\mathbb{R}}
\newcommand{\E}{\mathbb{E}}

Now every author writes \vect{x} and \argmin_\theta, and the paper looks the same no matter who typed it.

One rule for the whole team

Nobody defines a macro inside a section file. If you need a new one, add it to macros.tex.

That is the entire policy. It means a notation change, such as switching from bold vectors to arrows, is a one-line edit instead of a search through six files.

Catch the leaks before submission

People will break the rule at 2 AM. A quick search finds the stragglers:

grep -rn --include="*.tex" "\\\\newcommand\|\\\\def\|\\\\DeclareMathOperator" sections/

Anything that shows up in sections/ should move to macros.tex. If you work in a browser editor, the project-wide search does the same job.

Two small habits that help

Name macros by meaning, not by look. \loss ages better than \mathcal{L}, because you can change what the loss looks like without touching the text.
Comment the unusual ones. One line like % empirical risk over the training set saves a co-author from guessing.

Why this matters more with co-authors

When several people edit at once, small inconsistencies multiply fast. Splitting the paper into one file per section prevents edit collisions, and a shared macros.tex keeps those separate files speaking the same language. It is the cheapest piece of structure you can add to a team paper.

If your team writes together in LetX, the free plan has unlimited collaborators, so everyone can work in the same project at the same time. The macros.tex habit works the same in any editor, so use whatever fits your team.

Tomorrow: how to choose a collaborative research writing tool, with a 9-point checklist you can use on any option, including this one.

What is the most annoying notation inconsistency you have found in a paper? Tell me in the comments.

How to Write a Research Paper With Co-Authors Without Version Chaos

letx app — Mon, 26 Oct 2026 09:28:09 +0000

It is two days before the deadline. Your advisor sends paper_final_v7.docx. Your co-author sends paper_final_v7_REAL.docx. Both contain edits the other one lacks, and the results section exists in three different versions.

If that sounds familiar, the problem is not your co-authors. Collaborative research writing breaks because most papers are written with tools built for one person, then passed around like a baton.

Three failures cause most of the pain:

Competing copies. Email attachments create a new "latest version" every time someone hits save.
Silent overwrites. Two people edit the same section, and one person's work disappears without anyone noticing.
Unclear ownership. Nobody knows who is responsible for the related-work section, so it gets written twice or not at all.

The fix is a small set of habits plus one shared workspace. Here are the habits first.

1. Keep one source of truth

Pick a single place where the current draft lives and ban every other copy. If a file is attached to an email, it is a snapshot, not the paper. A cloud editor that every author opens in the browser removes the question of which version is real.

2. Assign section owners before anyone writes

Write the outline together, then put one name next to each section: abstract, introduction, related work, method, experiments, discussion. Owners write the first draft; everyone else comments. This single step prevents most duplicated work.

3. Comment instead of rewriting

When you disagree with a sentence in someone else's section, leave a comment that says what and why. Rewrite only after the owner agrees. Comments keep a record of reasoning, and they stop the quiet edit wars that sour co-author relationships.

4. Use real-time editing for the final stretch

In the last 48 hours, several people often need to touch the same file. Real-time collaboration means you see each other's cursors and changes as they happen, so merges stop being a manual chore. Tools built on CRDTs such as Yjs merge concurrent edits automatically.

5. Freeze the macros and the bibliography early

Agree on notation macros (\newcommand), citation style, and a shared .bib file in week one. Changing \mathbf{x} to \boldsymbol{x} across a 9-page paper the night before submission is how typos get born.

6. Compile often, and compile for everyone

A draft that compiles on one person's laptop but not on another's is a trap. Compile in a shared environment so everyone sees the same PDF, the same fonts, and the same errors. If you hit that wall, my earlier post on 7 advanced LaTeX hacks for AI and CS researchers covers layout and compile-time fixes.

Which setup fits your team?

Setup	Real-time co-editing	One source of truth	Setup effort
Email + Word/LaTeX files	No	No	None
Git + local LaTeX	No (merge by hand)	Yes	High
Browser-based LaTeX editor	Yes	Yes	Low

LetX is the browser-based option I build. It has live PDF preview, SyncTeX navigation, version history and 1000+ templates. The free tier has unlimited projects, unlimited collaborators and 40 compiles per day, and you can import an existing project, including an Overleaf export, as a ZIP. Real-time editing runs on Yjs, so concurrent edits merge instead of overwriting each other, and the built-in AI assistant, Lexi, can propose edits and compile to check them.

Try it on your next paper

You do not need to change everything at once. Start with rules 1 and 2 on your next draft: one shared place for the paper, and a name next to every section.

If you write in LaTeX, import your project at letx.app and invite your co-authors with a link. I read every piece of feedback, so if something feels clumsier than your current setup, tell me in the comments.

What is the worst co-author version mix-up you have lived through, and which rule would have prevented it?

7 Advanced LaTeX Hacks Every AI & CS Researcher Needs Before Submission published

letx app — Tue, 18 Aug 2026 18:30:56 +0000

It is 3:00 AM, twelve hours before the NeurIPS or ICLR submission deadline, and your double-column floating figure just jumped three pages downstream, turning your tight 8-page draft into a 10-page layout violation. If you have ever spent more time debugging ! Package tikz Error: Memory full or hunting down orphaned citation numbers than fine-tuning your model's hyper-parameters, you know the quiet desperation of academic typesetting under pressure.

LaTeX remains the undisputed gold standard for technical publishing, yet most computer science and machine learning developers rely on basic templates and legacy workflows copied from decade-old StackExchange answers.

Here are 7 advanced, field-tested LaTeX hacks that will optimize your compilation pipeline, save your layout under strict page limits, and shave hours off your paper writing workflow.

1. Reclaim Lost Page Space with `microtype` Sub-Pixel Optimization

When you are 6 lines over an 8-page conference limit, cutting meaningful technical content feels like amputating a limb. Before you delete a crucial baseline description, enable font expansion and margin kerning via the microtype package.

microtype adjusts font kerning, letter spacing, and hyphenation at a sub-pixel micro-typographic level. It subtly stretches or shrinks line widths to eliminate awkward word wraps ("widows" and "orphans") without altering font sizes.

% Add to your preamble (works with pdfLaTeX, XeLaTeX, and LuaLaTeX)
\usepackage[activate={true,nocompatibility},final,tracking=true,kerning=true,spacing=true,factor=1100,stretch=10,shrink=10]{microtype}
% Micro-adjust spacing between characters
\microtypecontext{spacing=noninclusive}

Result: You typically gain 10–25 lines across an 8-page paper without any perceptible change to visual readability or reviewer compliance.

2. Fix Floating Figure Chaos in Two-Column Papers with `stfloats`

Double-column templates (such as IEEE, ACM, or NeurIPS) frequently misplace full-width environment floats (\begin{figure*} or \begin{table*}). By default, LaTeX pushes full-width figures to the top of the following page, often throwing your figures several sections out of order.

Include stfloats to enable bottom placement ([b]) for two-column floats and force strict ordering:

\usepackage{stfloats}

% Enables double-column floats at the bottom of the page
\begin{figure*}[b]
  \centering
  \includegraphics[width=0.95\linewidth]{figures/architecture_diagram.pdf}
  \caption{Overview of our proposed Transformer architecture with attention visualizer.}
  \label{fig:architecture}
\end{figure*}

Quick Float Placement Cheat Sheet

Float Specifier	Intended Behavior	Common Gotcha
`[h]`	Place float approximately here	Silently ignored if page capacity is full
`[t]`	Top of the current or next page	Default preference for most LaTeX engines
`[b]`	Bottom of page	Requires `stfloats` or `dblfloatfix` for `figure*`
`[p]`	Dedicated page of floats	Triggered automatically when floats pile up
`!`	Override internal layout constraints	Forces placement; can disrupt text flow

3. Externalize TikZ Graphics for 10x Faster Compilation

Vector graphics generated via TikZ produce gorgeous, scalable diagrams, but re-parsing complex geometric nodes on every document save slows compilation to a crawl.

Use the external library to compile TikZ graphics once into cached PDF snippets. LaTeX will automatically reuse the compiled PDFs unless the underlying TikZ code is edited.

\usepackage{tikz}
\usetikzlibrary{external}
% Enable caching in a dedicated subfolder
\tikzexternalize[prefix=figures/compiled_tikz/]

Compilation Speed Benchmarks (50-Page Manuscript with 12 TikZ Diagrams)

Pipeline Configuration	Cold Compile Time	Hot Re-Compile Time	Memory Usage
Standard Inline TikZ	42.4 seconds	41.8 seconds	High (480MB RAM)
Standalone `.tex` Subfiles	38.1 seconds	37.9 seconds	Moderate (310MB RAM)
TikZ Externalization (Cached)	43.1 seconds	3.2 seconds	Low (85MB RAM)

4. Create Publication-Grade Tables with `booktabs` + `siunitx`

Default LaTeX tables look amateurish when cluttered with vertical lines (|c|c|) and misaligned numbers. Top-tier conferences expect clean, professional typography with numeric alignment centered around decimal points.

Combine booktabs for formal horizontal rules with siunitx for automated decimal alignment:

\usepackage{booktabs}
\usepackage{siunitx}

% Configure decimal alignment precision
\sisetup{table-format=2.2, table-auto-round}

\begin{table}[t]
  \centering
  \caption{Top-1 Accuracy (%) on ImageNet-1k across baseline models.}
  \label{tab:results}
  \begin{tabular}{l S S}
    \toprule
    \textbf{Model Architecture} & \textbf{Baseline (\%)} & \textbf{Ours (\%)} \\
    \midrule
    ResNet-50                   & 76.13                  & 78.45              \\
    ViT-Base/16                 & 81.80                  & 84.12              \\
    ConvNeXt-Large              & 84.30                  & 86.91              \\
    \bottomrule
  \end{tabular}
\end{table}

5. Automate Cross-Referencing with `cleveref`

Stop manually writing Figure~\ref{fig:arch} or Section~\ref{sec:methods}. Hardcoded prefixes waste time and introduce inconsistencies when moving sections around during peer review.

The cleveref package automatically detects whether your target reference is a figure, table, equation, algorithm, or section, applying the appropriate capitalized label automatically:

\usepackage{hyperref}
\usepackage{cleveref} % MUST be loaded AFTER hyperref

% Usage in body text:
As demonstrated in \cref{fig:architecture} and detailed in \Cref{sec:methods}, our model outperforming prior baselines (\cref{eq:loss_function}).

6. Trim Unwanted Bibliography Metadata to Save Page Space

Massive BibTeX files exported from Google Scholar or Zotero often include irrelevant metadata like location, isbn, issn, url, or doi fields that spill over onto extra pages in the references section.

If using biblatex, suppress secondary fields directly in your preamble rather than editing hundreds of .bib entries by hand:

\usepackage[backend=biber, style=numeric-comp, sorting=none]{biblatex}

% Suppress non-essential reference fields automatically
\AtEveryBibitem{
  \clearfield{issn}
  \clearfield{isbn}
  \clearfield{doi}
  \clearfield{url}
  \clearfield{note}
  \clearlist{language}
}
\addbibresource{references.bib}

7. Standardize Math Notation with Centralized Custom Macros

When collaborating with multiple developers across institutions, inconsistent mathematical notation (e.g., one author writing \mathbf{x}, another writing \vec{x}, and a third writing \bm{x}) creates an unpolished paper.

Establish a single macros.tex file defining standard semantic shorthand for vectors, matrices, expectation operators, and loss functions:

% --- Math Shorthand Definitions ---
\newcommand{\R}{\mathbb{R}}                  % Real number set
\newcommand{\E}{\mathbb{E}}                  % Expectation operator
\newcommand{\mat}[1]{\mathbf{#1}}           % Bold matrices
\newcommand{\vec}[1]{\boldsymbol{#1}}       % Bold vectors
\DeclareMathOperator*{\argmax}{arg\,max}     % Argmax with proper limits
\DeclareMathOperator*{\argmin}{arg\,min}     % Argmax with proper limits

Take Your Developer Workflow to the Next Level

Mastering macros and preamble tricks helps eliminate layout bottlenecks, but local compilation failures, environment mismatches between co-authors, and merge conflicts during paper sprint weeks remain major productivity drains.

If you are looking for a modern, browser-based LaTeX environment built from the ground up for real-time developer collaboration, check out LetX.

Unlike legacy editors, LetX offers:

Sub-second real-time co-editing without lockouts or file-saving lag.
Instant preview compilation powered by optimized cloud container infrastructure.
Built-in GitHub sync and native BibTeX reference management.
Pre-configured conference templates (NeurIPS, ICML, IEEE, ACM) ready out of the box.

Try LetX for free today and make your next paper submission deadline completely stress-free.

We built a free collaborative LaTeX editor. Here's the part that was actually hard.

letx app — Sat, 08 Aug 2026 19:20:29 +0000

The deadline was nine hours out.

My co-author was in another timezone, editing the same main.tex I had open. We were passing the file back and forth over a shared drive like it was 2020. At some point we both hit save. A results section disappeared, and neither of us could say with confidence which copy was the real one.

That night didn't make me want to start a company. It made me want to throw my laptop in a river.

It's also why we built LetX — a free, real-time collaborative LaTeX editor that runs in the browser.

This post is about the engineering, not the pitch. Specifically: the part that took four times longer than we estimated, and why the obvious solution doesn't work.

First, the question every developer asks
"Why not just use git?"

We did. For a while it was great. Then it stopped being great, for a reason that has nothing to do with git being bad.

Git works when everyone editing the document understands git. In a research group, that's usually one or two people. The rest are statisticians, chemists, and supervisors who have a paper to write and no interest in learning what a rebase is.

I once watched a genuinely excellent statistician spend forty minutes resolving a merge conflict in a .bib file. That's not a workflow. That's a tax on someone whose time is worth considerably more than the tooling that consumed it.

There's also a structural mismatch. Git operates on line-level diffs, and LaTeX prose doesn't respect line boundaries. Reflow one paragraph and you've "changed" every line in it. Two people editing different sentences of the same paragraph produce a conflict git cannot resolve, because from git's point of view they rewrote the same line.

You can mitigate this — one sentence per line, latexdiff, semantic linefeeds. Every mitigation is a convention you now have to enforce socially across a group of people who did not agree to it.

Social solutions to technical problems don't survive contact with a deadline.

The actual hard part
Real-time collaborative editing is one of those problems that looks solved from the outside. Google Docs did it in 2006. There are libraries. How hard can it be.

Here's the shape of the problem. Two people type into the same document from different countries on different network conditions. Their edits arrive out of order. You need every participant to converge on an identical document, without a central referee deciding who wins, and without ever showing anyone a "someone else is editing, try again" dialog — which is just a merge conflict wearing a nicer outfit.

There are two established approaches.

Operational Transformation (OT) is what Google Docs uses. Every edit is an operation, and operations get transformed against concurrent ones before being applied. It works, and it's notoriously difficult to implement correctly — the transformation functions have to be right for every pair of operation types, and getting them subtly wrong produces divergence that only shows up under specific network timing.

CRDTs (Conflict-free Replicated Data Types) take a different approach: design the data structure so concurrent operations commute by construction. If operations commute, order stops mattering, and convergence is a property of the type rather than something you have to prove about your transformation logic.

We went with CRDTs, using Yjs. Same algorithm class Figma uses for multiplayer.

The tradeoff is honest: CRDTs carry metadata overhead. Each character effectively needs identity so the structure can order operations deterministically. Yjs is very good at compressing this, but "very good at compressing overhead" is not "no overhead."

For a 300-page thesis, that's a real consideration.

Why LaTeX makes this harder than it looks
Here's what a generic collaborative text editor doesn't have to worry about.

LaTeX is not prose. It's a markup language with strict structural requirements, and it fails loudly and completely on violations. One unmatched brace doesn't degrade the output — it kills the compile.

Consider two users editing this concurrently:

\begin{theorem}
Let $f: X \to Y$ be a continuous map.
\end{theorem}
User A wraps the statement in \textbf{...}. User B, at the same moment, edits inside the same line. Both edits are individually valid. The CRDT converges — that's guaranteed, that's the whole point of the type.

But converging on a consistent document and converging on a compilable document are different properties. The CRDT promises the first. It has no opinion whatsoever about the second.

Now scale that to environments:

\begin{align}
a &= b + c \
d &= e + f
\end{align}
If one user deletes \end{align} while another is typing inside the block, you get a document every client agrees on and no compiler will accept.

Generic text editors don't have this failure mode, because generic text doesn't have a compiler that rejects the entire file over a single missing token. A missing in HTML renders badly. A missing \end{align} in LaTeX produces nothing at all.

Reconciling CRDT convergence with LaTeX's structural requirements is where our estimate went wrong. Not by a little.

Estimates are like that.

The compile loop is a latency problem, not a throughput problem
Second architectural thing we got right early, mostly by accident.

Writing LaTeX is a loop:

edit → compile → look at the PDF → edit again
You run that loop hundreds of times a day. It's not a batch job — it's an interactive feedback cycle, and it should be measured like one.

This distinction matters more than it sounds. Optimizing for throughput means asking how many documents you can compile per minute across all users. Optimizing for latency means asking how long this user waits for this compile.

A queue is the clearest expression of the difference. Queuing is excellent for throughput and terrible for latency, and worse, it makes latency unpredictable — your compile time now depends on how many strangers happen to be compiling right now. Unpredictable delay breaks concentration in a way that consistent slowness doesn't. You can adapt to a compile that always takes three seconds. You can't adapt to one that takes one second or eleven depending on the time of day.

We target roughly a second, no queue. The interesting engineering question — how you isolate arbitrary user-supplied LaTeX, which can execute shell commands under the wrong configuration, while keeping cold-start low enough for interactive use — is a whole post on its own.

Note to author: dev.to readers will ask about compile sandboxing in the comments. Have a real answer ready — container per compile, gVisor, seccomp profile, -no-shell-escape, whatever you actually do. Don't hand-wave it. This is the single most likely technical question on this post.

Three constraints we set and refused to relax

The free tier has to be genuinely usable, not a demo.

Unlimited projects, unlimited collaborators, unlimited compiles. No per-seat charge for adding your advisor or the undergrad doing the figures.

This is a real constraint on the business and we took it deliberately. Existing cloud editors solved collaboration and then metered it — compile timeouts, caps on how many people can be in a document, version history behind a paywall. Version history is the one feature you need most on the day something goes wrong.

The people who most need LaTeX to be free are the people most likely to hit the paywall. Students, early-career researchers, labs outside well-funded institutions.

As an engineering constraint, "unlimited compiles on the free tier" is a much more interesting problem than it sounds. It means compile cost per user has to be low enough that the free tier doesn't scale into a fire.

Compiles are fast and unqueued. Covered above.
Unpublished work stays private.

Researchers hand an editor unpublished results, grant applications, and blind-review submissions. That's not ordinary user data and it shouldn't be treated as ordinary user data.

What we got wrong
We assumed people would come for the collaboration. Collaboration was the entire thesis of the product.

What people actually asked for, repeatedly, was templates.

Not because they couldn't write a preamble — because starting is the expensive part. Nobody wants to spend the first two hours of a submission hunting for the right IEEE class file, or reverse-engineering a department thesis format from a PDF a senior student emailed them.

So we built the library out to 600+ templates: IEEE, ACM, Springer, Elsevier, theses, CVs, posters, grant applications.

The lesson generalized further than templates. We'd been optimizing the middle of the workflow. The friction was concentrated at the very beginning of it.

If you're building a tool, it's worth asking which part of the workflow you've actually instrumented. We were measuring the part we found interesting.

Where we are
1,300+ students and researchers, across 90+ universities and research labs in 35+ countries.

That's a real number and a small one. I still read every piece of feedback, and a single well-argued complaint can change the roadmap in a week.

Free, browser-based, nothing to install. Real-time collaborative editing, live PDF preview, version history with rollback, SyncTeX, and ZIP import for moving an existing project across.

Next up, both early: an agentic LaTeX editor that can refine a section or insert a table without you leaving the document — LaTeX is unusually well suited to this, because the source is text and the output is verifiable, so you can actually check whether the model's suggestion compiled. And QuantumSketch, which turns a paper into slide decks.

If you write LaTeX with other people
letx.app — free tier, no install, import an existing project as a ZIP.

If the compile loop doesn't feel faster, I'd genuinely like to know why.

And if you've built collaborative editing on CRDTs and hit the structural-validity problem from a different angle, I want to hear how you handled it. That's the part I'm still least satisfied with.