AltoLeap is a small team by choice and intends to stay one. We are not trying to get to fifty people. The model only works if the person who scopes a piece of work is the person who builds it and the person who stays on it, and that stops being true past a certain size.
So there are not many openings, and the bar is specific rather than high in a general way. We are looking for people who can sit with a manufacturer's estimator for an hour, work out what the business actually does, and then go build it. The building part is table stakes.
Configure-price-quote and quoting systems for made-to-order and engineered-to-order manufacturers, production and order workflows, dealer and customer portals, reporting, dispatch and scheduling for transport operators, and the integrations that connect all of it to the ERP, CRM and CAD tools already in place.
That means the work is unusually close to the domain. On one build our configurator drives SolidWorks through its API to produce production-ready drawings. On another, a dispatcher's whole day runs on a screen we designed. You will learn how wedge-wire screens are specified and how a coach fleet is scheduled, because you cannot build either system without knowing.
It also means the problems are rarely novel in a computer-science sense and almost always novel in a business sense. If you want to work on distributed systems research, this is the wrong shop. If you want the thing you build to be running a factory floor next quarter, it is the right one.
No layers. You talk to clients. You will be on calls in your first month.
We map how the business actually runs before writing anything, and the work goes through a written product and technical spec first. Most of the value is in getting the process right, and most project failures we have seen are specification failures rather than engineering ones.
We use it in delivery and we build it into products where it genuinely helps, in quoting assistance, document and drawing checks, and conversational reporting. We are also straight with clients about when ordinary automation is cheaper and more reliable, and we expect the same honesty internally.
The team works across Canada, Guatemala and Jamaica, all of it within two hours of Eastern Time. That is deliberate. We are remote but not asynchronous-only, and there is real overlap in the working day because the work needs conversation.
Small team, so scope is broad and ownership is real. Nobody here is handed tickets.
We need someone who can take a manufacturer's quoting process from a whiteboard session to a working configurator without a spec being handed to them.
We need someone who owns the technical shape of a client's system end to end: the spec, the architecture, the build decisions, and the two or three people building alongside them.
Write to us anyway. We keep good people on file and we have hired off speculative emails before. Tell us what you have built and what you want to build next. A short, specific note beats a long, general one.
Yes. The team works across Canada, Guatemala and Jamaica, with real overlap in the working day. The Toronto office is the head office and the registered address rather than a place everyone reports to.
Yes. We already have team members in Canada, Guatemala and Jamaica, so working outside Canada is normal here rather than an exception. All three sit within two hours of Eastern Time, which is deliberate. Whether we can hire in a country we are not already set up in depends on the role and the arrangement, so ask rather than assume.
Sometimes, for specific work. Say so in your email and tell us your availability and rate.
Rarely. It is not a judgment about juniors, it is that a team this size has nobody spare to mentor properly, and it would be unfair to bring someone in on that basis. If you are early career, the honest answer is that a larger team will serve you better right now.
A conversation with Lamar or Dean, then a technical conversation about work you have actually done rather than a whiteboard puzzle, then a paid short piece of real work where it makes sense. We try to keep it to two to three weeks.
An email to careers@altoleap.com, with something we can look at. Code, a system you built, a write-up of a problem you solved. A résumé is fine but it is the least interesting thing in the envelope.
The clearest picture of the job is the work itself: how we scope it, what we build for manufacturers, and the quoting systems that make up most of it.