About Achar

Achar began with a complaint that is now old enough to be boring: the content was in one system, the shape of it was in another, and the code that knew what it meant was in a third. Every team that shipped a website had a document somewhere describing the fields, and that document was always slightly out of date.

What we build

A content lake, a query language, and a studio. The lake stores documents rather than rows. The language reads them without an endpoint per shape of query. The studio is generated from the same model the API enforces, so the form an editor fills in and the validation a request is held to are the same description read twice.

You will change your design system three times in five years. You will change your content model once, badly, if you are not careful about it.

That asymmetry is why we put the model first. A schema is not configuration here — it is the schema. It is what the studio draws, what the API validates against, and what a query may rely on. Change it in one place and every surface that read it sees a different description of the same content.

How we work

Structured content is a discipline before it is a product, so we write about it. Almost everything on this site is a document in a dataset the product itself serves — including this page, which was written in the studio, saved as a draft, reviewed, and published.

• We ship the product and use the product, in that order and not the other way round.
• We write the reasoning down. A decision without its reasons is a decision somebody will reverse by accident.
• We keep the API small enough to hold in your head, and we add to it reluctantly.