LevelOps
frStart free

Company

Work on the boring problem that costs the most

We hire operations people who code and engineers who understand wholesale. Small team, Montreal, bilingual. Three roles are open right now, listed below with the application form, and this page still says plainly how we work and who tends to fit before you apply.

See how it works Write to us

What we are

A small team in Montreal building order automation for B2B wholesalers, alongside ERP, MRP and Shopify implementation work for manufacturers and distributors. The problems are unglamorous and the impact is immediate, which suits a particular kind of person and frustrates others.

The two halves of the business are not separate departments. The implementation work is how we find out what the product is missing, and the product is what we do with the pattern once we have seen it enough times. That means most people here end up closer to a customer's actual operation than they would be at a pure software company, and closer to a codebase than they would be at a pure consultancy.

The work is also concrete in a way that not everybody enjoys. There is no long horizon on which the value might eventually appear. Someone was retyping purchase orders on Monday, and by Friday they are reviewing draft orders instead. You can see whether what you built worked, which is either the best part of the job or the worst, depending on your temperament.

How we work

Six things that are true about working here. They are not perks, they are trade-offs, and it is worth knowing which side of each one you would rather be on.

Close to the operation

You will speak to the person who actually receives the orders, not to a project sponsor's summary of what they said. Most of what we build comes from that conversation rather than from a roadmap meeting.

Small team, wide scope

Nobody owns a narrow slice. That means unusual range and real ownership, and it also means you will occasionally do work that is beneath your title because it needs doing today.

Additive, not rewritten

We build on what exists rather than replacing it, in customer systems and in our own. If your instinct on seeing unfamiliar code or an unfamiliar process is to start again, this will grate.

Bilingual by default

English and French, daily, with customers on both sides. Franglais is fine internally, and anything client facing goes out in one language, done properly.

Honest with customers, including when it costs us

If automation is not a merchant's bottleneck, we say so during the audit. Being able to help two ways is what makes that affordable, and it sets the tone for how we expect people to talk internally too.

Measured, not asserted

Claims get numbers attached or they get softened. That applies to marketing copy, to product decisions and to your own account of what your change improved.

Who tends to fit

Three profiles that have worked well here. They overlap more than you might expect.

Operations people who code

You have run a process, not just observed one. You know why a workflow fails on a Tuesday afternoon, and you can build the thing that fixes it rather than writing a specification for someone else to build.

  • You have owned a number that someone else's work moved
  • You are comfortable in a spreadsheet and in a terminal

Engineers who would rather remove a job than add a dashboard

Given a slow manual process, your first instinct is to delete steps, not to instrument them. You are more interested in whether a person stopped doing the task than in how elegantly the task is now visualised.

  • You care about the edge cases because that is where trust is won
  • You would rather ship something checkable than something clever

People who like other people's messy documents

Someone has to find a handwritten order form genuinely interesting. Real purchase orders are inconsistent, badly scanned and occasionally wrong, and the work is making sense of them without pretending they will improve.

  • You are patient with ambiguity in inputs and strict about outputs
  • You enjoy the detail of case packs, price lists and part numbers

Who probably does not fit

Written plainly to save everyone time. None of these are character flaws, they are just a bad match for this particular team.

  • You want a narrow, well defined remit with clear boundaries around it
  • You would rather work on the platform than on the customer's problem
  • You find operational detail tedious and want to stay at the architecture level
  • You prefer building autonomous systems and consider a human review step a design failure
  • You want a large team, a defined ladder and a published promotion cycle
  • You would rather not be measured on whether the thing you built actually removed work

Areas we hire into

Areas rather than titles, because the shape of a role here usually follows the person who arrives. If your strength is in one of these, the note is worth writing.

  • Product engineering, on the app that reads documents and writes Shopify orders
  • Applied AI and document extraction, including matching messy descriptions to a catalogue
  • ERP and MRP implementation, for manufacturers and distributors
  • Shopify and B2B build work, including companies, price lists and payment terms
  • Customer onboarding and support, in English and French
  • Operations analysis, the audit work that maps how orders actually flow

Open roles

Three, as of September 2026. Each one exists because a specific piece of work is not getting done, not because we are filling in an org chart. Every posting includes the part that is hard, so read that part before you apply.

Principal Engineer

  • Engineering
  • Montreal, Canada
  • Full time
  • Remote friendly
Apply

The senior engineer on PDF to Order, the Shopify app that reads the purchase orders a wholesaler's customers send by email and writes Shopify draft orders for a person to approve. You would own extraction and matching accuracy, the reliability of the pipeline behind it, and the write paths into Shopify, Katana MRP, Odoo and QuickBooks. Small team, so this is hands on with real architectural authority, not a role that reviews other people's pull requests.

What is hard about it: accuracy is the product. Our measured error rate is 0.5% against about 3% for manual entry, which is 6x fewer with a human signing off on every order, and defending that number means handling documents nobody anticipated, at a customer's month end, in front of the person who was promised this would save them time. No test suite covers other people's paperwork. The job is building systems that fail in checkable ways, and being honest about the confidence score rather than making a silent best guess. Our current engineering agenda is published on the roadmap page, so you can judge the work before you apply rather than after.

What you would do

  • Own extraction and matching accuracy end to end, measured on real customer documents rather than a benchmark set
  • Design the matching layer: buyer part numbers, obsolete catalogue references and free text descriptions resolved against a Shopify catalogue with a confidence score, on Postgres with vector search
  • Keep the pipeline honest: job queues that actually retry, idempotent writes, Shopify Admin API rate limits, and monitoring that tells us before a merchant does
  • Build and maintain the write paths into Shopify, Katana MRP, Odoo and QuickBooks, plus the n8n workflows that hold the awkward joins together
  • Ship what is in build now: per account extraction instructions in plain language, line item tables that break across a page boundary, notes typed into the email body beside the attachment, and a second parsing model run head to head against the current one
  • Set the human review boundary, deciding what the system may do quietly and what has to stop for a person, then make the stop useful
  • Sit with merchants on the documents that failed, and change the design after that conversation rather than defending it
  • Raise the level of the rest of the engineering work through review, specification and pairing, not through a management layer

What we need

  • Enough production experience that you have owned a system end to end, including the on call consequences, rather than components of one
  • TypeScript and Next.js, since the app and this site both run on them
  • Relational data modelling in Postgres, and comfort with queues, retries, backfills and background jobs
  • Practical LLM work: prompts under version control, evaluation against real inputs, handling of bad output, and knowing when a deterministic rule beats a model
  • Integration work against APIs you do not control, including the undocumented parts and the ones that change without notice
  • A preference for removing a step over instrumenting it, and no allergy to talking with the person doing the order entry

Nice to have

  • Shopify app development, especially the B2B objects: companies, catalogs, price lists and payment terms
  • ERP or MRP experience with Katana, Odoo, NetSuite, Business Central or similar
  • Document extraction at scale: scan quality, table structure, multi page documents, case and pack conversions
  • Security and compliance work, since SOC 2 Type II is under way
  • French, because some merchants and plenty of their documents are in French

Growth Marketing Specialist

  • Marketing
  • Montreal, Canada
  • Full time
  • Remote friendly
Apply

The first marketing hire, owning search, GEO, the Shopify App Store listing and outbound for PDF to Order. Today one person owns every marketing line here, and the constraint is conversion rather than spend, so this is a role about making existing demand land rather than buying more of it. You would be judged on non brand search clicks, relevant referring domains, listing conversion from view to install, and meetings booked.

What is hard about it: nothing here can be asserted. Every claim on this site has to be traceable to a recorded customer call, a named review or a dated data pull, and we do not publish a number we cannot source. That rules out most of the copy a growth marketer is used to writing. The other hard part is that our category has almost no search volume under its own name, so the work is winning established vocabulary like purchase order automation and order processing software, while making the answer to a buyer's actual question findable by an AI assistant, which is the number one documented discovery channel in our own persona research.

What you would do

  • Own bottom of funnel search: the money queries where our pages already impress and do not earn the click, rewritten for the intent behind the query rather than for volume
  • Own GEO as part of the same bet, not as a side channel, which means answering the buyer's question on our own pages and keeping FAQ schema matching the visible page word for word
  • Own the Shopify App Store listing in English and French, and treat view to install conversion as a weekly number rather than a quarterly report
  • Run outbound: lists of North American Shopify B2B wholesalers and distributors, sequences by industry, measured on meetings booked and not on sends
  • Turn recorded customer calls into copy, so the words on the page are the buyer's rather than ours
  • Write for four buying roles at different awareness stages: the operations leader or founder who signs, the order entry lead whose adoption decides renewal, the sales champion who opens the door, and the technical validator who can quietly kill it
  • Keep the case studies and proof assets current, since outbound and the listing both lean on them
  • Say when a number cannot be traced, and take the softer claim over the better one

What we need

  • You have owned an SEO or content programme yourself rather than briefing an agency to own it
  • You can write in the voice on this site: direct, ROI first, specific, no filler, and no em dashes
  • You are comfortable in the measurement layer, Search Console, Ahrefs and enough SQL to check a number instead of asking someone for it
  • You will learn the operational detail, case packs, price lists, payment terms, draft orders, because a wholesaler spots copy that gets it wrong in one line
  • You can hold a weekly cadence on a handful of indicators instead of producing a monthly deck

Nice to have

  • Shopify ecosystem experience, whether App Store listings, apps or partner marketing
  • B2B or wholesale background, having sold to operations people rather than to consumers
  • Google Ads on a small budget, where cost per install matters and cost per lead does not
  • Having checked what AI assistants currently say about a category, and changed it
  • French, since the listing and much of the site ship in both languages

Engineering Intern

  • Engineering
  • Montreal, Canada
  • Internship
  • Remote friendly
Apply

A hands on internship on PDF to Order, working on real merchant documents rather than a side project nobody ships. Expect a term spent on extraction failures, catalogue matching, and the small tooling that makes a bad document diagnosable. We only take interns when someone senior has the time to mentor properly instead of assigning tickets, which is why this is open now.

What is hard about it: the inputs are other people's paperwork, so the interesting part is rarely the algorithm. It is a scanned page at an angle, a case pack written three ways in one document, or a part number the buyer stopped updating years ago. That is either the best kind of puzzle or a tedious one, and it is worth knowing which of the two it is for you before you apply. The internship is scoped so that you finish something. By the end you should be able to point at code in production and say what it does and why it was hard.

What you would do

  • Reproduce and fix real extraction failures, starting from the document that broke rather than from a ticket description
  • Turn real documents into test fixtures, so a fix stays fixed
  • Build small tools that make a failure legible, for example a clear diff between what the document said and what the draft order became
  • Help evaluate catalogue matching: score the guesses, find the pattern in the misses, feed it back into the matching rules
  • Write down what you learn about how a given customer's documents behave, because a lot of that knowledge is currently in people's heads

What we need

  • In, or recently out of, a computer science, software engineering or related programme
  • You have built something outside coursework, and can talk about the part that broke
  • TypeScript or another typed language, and enough SQL to answer your own question
  • Comfortable being wrong in public, because review here is open and quick
  • Genuine curiosity about the unglamorous half: why a purchase order in a spreadsheet does not line up with a catalogue

Nice to have

  • Any LLM work beyond a chat window: prompts in version control, evaluation, handling bad output
  • Comfort working in both English and French
  • Any warehouse, retail or operations job, which teaches more about this problem than a course does
  • A GitHub, a demo or a repository you would be happy to walk us through

Compensation is not published on this page and we are not going to invent a range to fill the field. It comes up in the first conversation, and the form asks what you are expecting so that we can be straight with you before either of us spends a week on it. The team is in Montreal and that is where the centre of gravity is. Remote works for the right person, and if it will not work for one of these roles we will tell you early rather than in week three.

Apply

Three steps, about five minutes, ending with a 90 second video. Who you are, then the role and why, then you on camera saying what you would want to work on. There is no CV upload, because two written answers and 90 seconds of you tell us more than a CV does.

  1. 1. About you
  2. 2. The role
  3. 3. Say it out loud

City and country. We work across time zones, we just need to know yours.

One link is plenty. Whichever one actually shows your work.

What you send is used to consider your application. We do not share it outside the team.

The video can be a phone camera in one take, or a link to something you recorded elsewhere. What you send is used to consider your application and is not shared outside the team, and if you would rather we did not keep it on file for later roles, uncheck the box on the last step.

How to reach out speculatively

If none of the three postings above is yours, this is the other way in. Write anyway, and make it easy for us to answer well.

  1. 01

    Say what you would fix first

    Read a couple of pages on this site, look at how the product describes itself, and tell us the first thing you would change or the first thing you think we have got wrong. A paragraph is plenty.

  2. 02

    Show one thing you built or ran

    Code, a process you redesigned, a system you implemented, a number you moved. One concrete example beats a full history, and we would rather hear about the awkward one than the flattering one.

  3. 03

    Tell us where you are and what you want

    Location, languages, the kind of work you want more of and the kind you want less of. Being direct about this early is faster for both of us than discovering it in week three.

  4. 04

    Expect a real answer

    We read speculative notes and reply, including when the reply is that there is nothing right now. If there is something, we will tell you what it might look like and what the range is early rather than late.

Write through the contact page. English or French, whichever you would rather be judged in.

What we will and will not promise

We will not put a fake job posting on this page to collect applications, and we will not describe a benefits package to make a small company look like a big one. When there is a real role, the details will be real and specific to it, including compensation range discussed early in the conversation rather than at the end.

What we can promise is that a speculative note gets read by someone who can act on it, and answered. That is easier for us than for most companies precisely because there are not many of us.

We can also promise the work is real. There is no team here whose output is a document nobody reads. If you build something, a merchant uses it that week, and you will hear directly whether it helped. Some people find that exposure uncomfortable, and it is better to know that about yourself before you arrive than after.

Questions candidates ask

Are you hiring right now?

Yes. Three roles are open as of September 2026: Principal Engineer, Growth Marketing Specialist and Engineering Intern, all three described on this page with an application form under them. We still open roles when the work genuinely exceeds the people rather than on a schedule, so if none of the three is yours, a speculative note is read and answered anyway, and a good one has changed our plans before.

What does the job actually involve?

Being close to somebody's operation. Whether you are writing code or running an implementation, the work involves understanding how a real wholesaler receives and processes orders, then removing steps from it. If you would rather not talk to the person doing the typing, this will be frustrating.

Do I need to be in Montreal?

The team is in Montreal and that is where the centre of gravity is. If you are elsewhere, say so in your note and we will be straight with you about whether it can work for the kind of role we might open, rather than stringing you along.

Do I need to be bilingual?

It is an advantage, not a requirement. We work in English and French daily, with customers on both sides, and support is bilingual on every plan. Plenty of the work is doable in one language, but more of it opens up in two.

What areas do you hire into?

Product engineering, applied AI and document extraction, ERP and MRP implementation, Shopify and B2B build work, customer onboarding and support, and operations analysis. We do not maintain a standing list of titles, because the shape of a role usually follows the person.

Do you post salaries?

We do not publish compensation on this page, because we are not going to attach a number to a role that does not exist yet. When there is a real opening we discuss range early in the conversation rather than at the end.

What is the interview process?

A conversation about work you have done, then something concrete: a real problem from our world, discussed or worked through rather than a puzzle round. We try to make the process look like the job, and to give you a decision quickly either way.

What happens after I send the application form?

We read the written answers and watch the video ourselves, and a person replies either way, normally inside a week. If it looks like a fit, the next step is a conversation about work you have actually done, then something concrete from our world: a document that broke, a page that does not convert, a matching problem, worked through rather than a puzzle round. Compensation range comes up in that first conversation, not at the end.

Is the 90 second video mandatory?

Not strictly. The form sends without one and we still read those applications. It is the strongest part of an application here though, because 90 seconds of you saying what you would want to work on tells us more than a page of prose, and we watch every one. Phone camera, one take, no script is exactly right. If you would rather record it elsewhere, paste a Loom, unlisted YouTube, Drive or Vimeo link and check that we can open it.

Is the engineering internship paid?

We do not publish compensation for any of the three roles on this page, including the internship, and we are not going to put a number here that we have not written down internally. The form has a field for what you are expecting, and whatever you write there gets a straight answer in the first reply rather than after three rounds of interviews.

What if I have no wholesale background?

Then be curious about it. Nobody arrives knowing how case packs, price lists and payment terms interact. What matters is whether you find that kind of detail interesting rather than beneath you.

Do you take interns or new graduates?

Occasionally, when there is someone who can mentor properly rather than just assign tickets. If that is you, say what you want to learn and what you have already built, and be specific about both.

How should I write to you?

Through the contact page. Tell us what you would fix first, in a paragraph, and include something you have actually built or run. That single question tells us more than a CV does, and the answers that stand out are always specific.

Read before you write to us

Our story

Why a consulting practice ended up building a product, and what we believe.

Our team

Who is here now, and the mix of operations and technology.

How it works

The product in four steps, which is most of what you would work on.

Case studies

The kind of outcome the work is measured against.

B2B order management

The operational world our customers live in, in some detail.

Press and media

The company facts, stated plainly and without embellishment.

Tell us what you would fix first

One paragraph on the first thing you would change, plus one thing you have built or run. Write in English or French. We read these and we answer, including when the answer is not right now.

Montreal based. English and French. Three roles open, and a real reply either way.

Write to us Read our story

In numbers

Two halves
Implementation consulting and product, and most people touch both
English and French
Both languages used daily, with customers and internally
Montreal
Where the team is based
Three roles open
Principal Engineer, growth marketing, and an engineering internship