Company

Who you actually work with

We are small. The people who scope your engagement deliver it, and the people who answer support can read the code. That has real advantages and real disadvantages, and the disadvantages are the ones worth reading.

Want to talk to someone?

You will speak to a person who implements this, not to a qualification call.

1 / 3
No sales-to-delivery handoverSupport is engineeringSmall enough to be a constraint

Company

Six things a small team changes.

Three of these are advantages and three are limitations. Both lists are honest.

No handover

The person who scopes your engagement delivers it. Partner capacity and turnover was the primary cause in 8% of the stalled implementations we have been called into, and this removes that failure mode entirely.

Support is engineering

Whoever answers your ticket can read the code and change it. There is no tier structure to escalate through and no first-line function reading from a script.

Decisions are fast

A scope change, a pricing question, or an exception takes one conversation rather than an approval chain. That cuts both ways — we can also say no quickly.

No capacity buffer

When demand exceeds our team, engagements queue. We will tell you a start date honestly rather than accepting work we cannot staff, and sometimes that date is months out.

No local presence

We deliver remotely across the United States. An established Acumatica or Business Central partner in your city offers something we genuinely cannot.

No vertical specialists

For industries we have not worked in, you get generalists who learn quickly rather than someone with thirty deployments in your sector. That is a real gap and it is why some of our industry guides are thinner than others.

The trade, stated plainly

The mid-market ERP industry runs on partner channels because vendors cannot maintain implementation capacity across every industry, region, and business shape. That model gives buyers local presence and vertical depth we do not have.

It also produces the variance we spend a lot of pages warning buyers about — across the stalled implementations we have seen, the spread between a strong and a weak partner exceeded the spread between the products they were implementing.

We chose the other side of that trade: deliver directly, keep quality predictable, and accept that we cannot scale to meet demand or cover every vertical. Anyone telling you their go-to-market model has no downside is describing marketing rather than economics.

We removed the partner-variance failure mode by removing the partners. That also removed the local presence, the vertical specialists, and the capacity buffer.

How the team is organised

There is no separation between the people who build the product and the people who deliver engagements. That is unusual and it is deliberate: the fastest way to learn what is wrong with a product is to implement it for someone who is paying attention.

Practically, an engagement has one lead who stays with it from scoping through to handover, drawing on whoever else is needed. You will not receive a project team roster with names you never meet, because we do not have enough people for that to be possible.

Who answers support

Engineers, on rotation. A critical issue reaches someone who can change the code the same day rather than someone who opens an internal ticket. We measure the mix of ticket categories at ninety days, and where how-to questions dominate we run more training at no charge rather than treating the volume as engagement.

Who you meet in a sales conversation

Someone who implements. There is no qualification call, no SDR layer, and no handover from an account executive to a solutions engineer. If we tell you in a first conversation that we are the wrong fit, that is a technical judgement rather than a lead-scoring outcome.

What this means for your risk assessment

Key-person dependency is real and you should weigh it. A small team means a small number of people hold operational knowledge, and that is a genuine concentration risk in a vendor you would run your finance function on.

The mitigations we can offer are the same ones that address our size generally: a complete scheduled data export in open formats to storage you control, documented in a form a competent team could load elsewhere, and source escrow on applicable plans. Neither offsets the risk entirely and we would not claim they do.

If you need what we cannot offer

Local hands-on capacity across many industries, a named vertical specialist, or a guaranteed start date next month. Those are legitimate requirements and an established partner-led product serves them better than we do. We would rather say that here than in a first call after you have spent time evaluating us.

Questions

Common follow-ups.

How big is the team?
Small enough that it is a constraint on how much work we can take, and we will tell you an honest start date rather than accepting an engagement we cannot staff.
Will the people I meet do the work?
Yes. There is no sales-to-delivery handover, largely because we do not have enough people for one to be possible.
Who answers support tickets?
Engineers on rotation. A critical issue reaches someone who can change the code that day rather than someone opening an internal ticket.
What about key-person risk?
Real, and you should weigh it. The mitigation is the same as for our size generally — a complete scheduled export in open formats that a competent team could load elsewhere.
Do you have specialists in our industry?
For some industries yes, for others you get generalists who learn quickly. That gap is why some of our industry guides are thinner than others.

Small enough that it is a constraint.

No handover and no script. Also no local presence, no vertical bench, and no capacity buffer.