Working with Primacy /

Working with our product team

You'll be working across the platform (like our parsers, legislation extraction and transformation pipeline, and APIs), products (web apps designed to serve specific audiences), and solutions (apps for specific clients). At some point in our growth, dedicated teams will be established for each.

We're asynchronous remote

Most of our conversation occurs via text. We don't try to replicate an office with video chat. It's asynchronous. (We're not watching for replies on Slack.)

We're using for hiring so we're limited to their availability.

We're lean

We care about small, valuable releases delivered frequently for tight feedback loops. We take the same approach for our process improvement.

We try to make conscious decisions balancing system quality attributes. (Everything is a trade-off!) We purposefully take on technical debt and diligently pay it down.

You can ask us for more details about our current practices and the principles behind them.

Developers: We're type-first

We design with types and spend most of our time using fsharp and TypeScript, but we'll happily pick a technology that's uniquely suited for the job. Our code style is functional but not pure. You'll see functional principles reach out beyond code to the way we design delivery pipelines and infrastructure.

You can ask us for more details about our current technology choices.

Designers: We're close to users

We care about the product team being close to the people on the other side of the software. We minimize the layers of translation and interpretation so we can get fast feedback and build better products.

You can ask us for more details about how we approach design.

Product managers: We’re innovators and creators

We are naturally curious about the world and care to make it better. We are critical but constructive. You’ll see the scientific method deeply ingrained in our work.

You can ask us more about what we are working on.


If it helps you self-assess your fit, this is the position description as stated in employment agreements for individual contributors:

  • Develops features and improvements for Primacy's products and solutions ('work').
  • Collaborates with other team members and stakeholders to deliver work.
  • Divides work into smaller but valuable tasks to contribute frequently.
  • Solves complex technical problems.
  • Contributes work that maintains or improves the quality of the work.
  • Reviews others' work and advocates for the maintenance of quality.
  • Identifies impediments to team efficiency. Designs and implements ways to reduce them.
  • Represents Primacy publicly in communication and community collaborations.



Most of our communication is via asynchronous text, not video calls. We'd want to hire in the same manner. Traditional interviewing selects those who are swift ad-libbers, but our hope is to find deliberative thinkers and cogent writers. We're looking for how well ideas are expressed, not grammatical precision or flourish. We'll chat with you via email. There's no on-the-spot questioning so you can answer in your own time.


We want to know what you do and what it's like to work with you, as we're sure you do us.

This is a summary of the process. If you want to see the process precisely as we execute it, including our assessment criteria, you can read our hiring page.

Stage 1: Screening

We want to hear about something you've made in the last year (or so) that demonstrates what you do well. This assesses comprehension and communication skill.

Send us a short note telling us what it is and why this is the work that demonstrates your skills best. You have our permission to boast — you ought to. You're welcome to ask any questions you have as we go, though they may be (anonymized and) collected here under a FAQ section.

Stage 2: Assessment

If it makes sense to keep chatting, we'll ask to be walked through it. This assesses language, analysis, design, and professional skills.

Tell us why this work exists. Tell us the story behind it. Tell us about the complexities you encountered (and conquered?). Ideally, show us the work (i.e. link to code on GitHub or treatments on Behance). However, we realize not everyone can share their work so you can use pseudocode or other illustrations instead to communicate areas of interest.

If you're a developer or designer, this is an entirely written assessment. If you're a product manager, this is a mix of written and video call interview.

Stage 3: Work trial

Next, we'd like to try working with you. This assesses teamwork and product, technical, or design skills.

We'll ask you to self-evaluate your level and draw up a work trial agreement for a fixed period of two weeks at a daily rate of base × level scale factor × region scale factor ÷ 52 weeks ÷ 5 days with the values from our compensation spreadsheet. If you can't do that (you're already employed, for example), we'd still like to spend some time working with you but it can be part-time over a longer period.

We'll work together on 'regular' work. There are no coding challenges or design quizzes. We'll assign you actual work we need done but structured to ease you into the domain.

Stage 4: Employment or contract offer

If we deem each other "a good fit" then comes the offer for employment or contract.

We'll offer a competitive salary based on the cost of labour in your region and our interpretation of your skill level. The calculation is base × level scale factor × region scale factor × exchange rate and with the values from our compensation spreadsheet.


Our assessment is of communication and skill fit compared to our own skills and our pipeline of work.

Our criteria is as defined for your self-evaluated level. Unfortunately, judgement on things like communications will inevitably remain subjective to the current team.


Send us a short note telling us about something you've made and why this is the work that demonstrates your skills best.