Come and build Folio.

The work

• The writing surface, where citations are structured objects rather than formatted text. That sounds like a detail until you realise they have to survive copy and paste, undo, two people editing at once, and export to Word without breaking.
• Or the integrity side: checking quoted text against the source it came from, reconciling references against the public citation databases, and producing a record a professor can actually verify.
• Or the institutional side, where a university runs Folio under its own name with its own rules about who sees what.
• And the parts nobody puts their hand up for. Migrations. The bug that only reproduces in one person’s document. The export that still has to be correct when a service upstream is having a bad day.

What you need

• You have built something and then lived with it in production, which is a different skill from starting things.
• Fluent in TypeScript and comfortable with a relational database.
• You have worked somewhere being correct mattered more than being clever.
• You test with the worst input you can find, not the tidy example, because in academic work the worst input is normal.

Helps, not required

• You have gone deep on a rich-text or canvas surface before.
• You have worked on something with real-time collaboration in it.
• You have shipped an export that had to be exactly right, in publishing, legal or finance.

The work

• The identity itself. Folio should read as something academic, not as another AI product, which mostly comes down to typography and restraint. There is a starting point in place; it needs someone to take it further.
• Illustration and icons. The hard part is that the ideas are abstract, so the usual visual shortcuts are no help. Nobody needs another robot.
• The writing. Headlines, the small print under a button, launch posts. Roughly half this job is words, and if that sounds like a chore it is the wrong job.
• Making it hold up in the awkward cases: in Arabic and Hebrew running right to left, in dark mode, on a small phone.

What you need

• Work you can show that has a point of view, not a folder of trends.
• You care about type at the level of a particular italic at a particular size, and can explain the choice.
• You write well. Not headlines in a portfolio, actual sentences.
• You have talked someone out of something that would have looked impressive and been wrong.

Helps, not required

• You can build what you design, at least to the point of a working page.
• You have set up a design system somebody else then used without asking you questions.
• You have worked in a language that reads right to left.

The work

• Talking to the people who decide: usually some combination of a dean, a registrar, someone in IT, and the faculty who will actually use it. They want quite different things, and the demo has to change accordingly.
• Procurement. Security review, the data agreement, a pilot with one department, a committee that meets once a month, and finding which budget it comes out of. It is slow and it is most of the job.
• Bringing the blockers back accurately. Institutions ask about integrating with their existing systems and about where their data is stored, and those answers decide deals. What is useful to us is the specific constraint, not a general note that it came up.
• Keeping accounts once they sign. Getting a department properly started, noticing when instructors quietly stop using it, and finding out why. One university that renews matters more than three that trial it and drift.

What you need

• You have sold into a university, or worked inside one, so the two-semester timeline does not surprise you.
• You can talk to an IT director without bluffing and to a dean without talking down.
• You are careful about what you promise. In this sector one oversold feature ends a relationship, and people compare notes.
• You are fine with a small number of accounts that each matter a great deal.

Helps, not required

• You have been through a procurement cycle from the inside.
• You have worked with the systems universities already run, and know what integration questions are coming.
• Arabic or Hebrew, given where the first institutions are.

The work

• The first ninety days of every institution. Importing the roster, working with their IT on sign-on, setting up branding, terms, courses, and who is permitted to see what.
• Training faculty who did not choose Folio and have taught the same way for fifteen years. That is persuasion as much as instruction.
• Being the named person the institution calls. Universities want to know who is accountable, and to begin with that is you.
• Renewal, which is decided long before it is discussed. Watching whether a department is actually running work through Folio, and stepping in early when it is not.

What you need

• You have onboarded organisations rather than individual users, and can run a training session for a room that did not ask to be there.
• You can hold a project together across months, because these rollouts are measured in terms.
• You write clearly enough that an institution trusts your follow-up email.

Helps, not required

• You have worked inside a university, in a registry, faculty office or IT department.
• You have moved an organisation off a system it had used for years.

The work

• Front-line response for students and instructors. Term time is deadline-shaped, so a problem at eleven at night before a submission is a genuine emergency.
• Reproducing issues properly, fixing the small ones, and handing engineering something they can act on rather than a forwarded complaint.
• The help documentation, which should be absorbing these questions before anyone has to ask them.
• Telling the rest of us what keeps coming up. Support sees the real failure modes weeks before anyone else does.

What you need

• Technical enough to reproduce a bug, read a log and run a query, even if you are not writing the fix.
• You write plainly and calmly to someone who is stressed and out of time.
• You can tell what is urgent from what can wait until Monday, and you are right most of the time.

Helps, not required

• You have supported an education product, or worked a university help desk.
• SQL, or the appetite to pick it up in a fortnight.

The work

• Single sign-on. SAML and OIDC against whatever identity provider the institution has, including the ones with inventive readings of the specification.
• Rostering. Getting students and staff into the right courses from the system of record, whether that arrives as a modern API or a file dropped nightly.
• Standards-based interoperability, so Folio can sit alongside an existing LMS instead of demanding it be replaced first.
• Making all of it debuggable. When a sync fails on the first morning of term you have hours, not days, and you need to know why immediately.

What you need

• You have shipped SAML or OIDC in production and dealt with a provider that did not behave as documented.
• You are comfortable with the unglamorous half: retries, partial failures, idempotency, and reconciling two systems that disagree about the same student.
• You can write documentation an institution’s IT department will follow without needing a call.

Helps, not required

• You know LTI, or education rostering standards, or have integrated a student information system before.
• You have been on the institution side of one of these projects and remember how it felt.