Have a Project?
You already know what you need: a migration with a date attached, an app that has to exist, a workflow rebuild, a rescue. This page is the shortest path from that to a scoped, priced plan.
How it starts
No booking widget, no discovery maze. Tell us what you're trying to get done; a founder reads it before anyone calls you, and we respond within one business day — with a point of view, not a script. The first 30 minutes are free: whether we're the right fit, how we'd approach it, and what we'd look at first. The boundary we hold, from How We Work: the moment work produces artifacts — inventories, findings, architecture, roadmaps — it's a paid engagement.
What project work looks like
Project engagements are fixed scope and milestone-billed: you know the price before we start, and payment tracks delivered milestones. The commercial mechanics are on pricing; every proposal names its GRID stage and line-items who does what, at what rate.
The usual shapes:
Assessments and QuickStarts
— fixed-price diagnosis and first implementations, from the assessment portfolio.
Migrations
— SharePoint Server to Online, file shares, tenant consolidations, planned in waves and validated before cutover.
Legacy exits
— Designer and Nintex workflows rebuilt, InfoPath forms replaced, before the retirement dates decide the schedule for you.
Builds
— Power Apps, automation, reporting, agents: scoped, built against the Ø Standard, and handed over with documentation and support.
Rescues
— the app or flow whose builder left. Stabilize first, understand it, then fix it properly — how rescues work.
Whatever the shape, "done" means the same thing: the work passes the Ø Standard — a named owner, no personal credentials, real documentation, monitoring, and a support path after go-live — so the project ends without leaving you a new orphan to manage.
What to bring to the first conversation
Recovering knowledge is part of the work, not a prerequisite for it.
The messier the situation, the more useful the call. But if you want to accelerate scoping, these help:
- The outcome in a sentence. "Old intranet gone by June." "This approval process out of email." "The InfoPath forms replaced."
- The systems involved. SharePoint, Dataverse, the ERP, the thing with no API — whatever you know.
- Rough size. Number of users, sites, forms, or workflows — estimates are fine.
- The timeline driver. A retirement date, an audit, a leadership mandate, something that already broke.
- Who owns it internally. The person who'll make decisions while the work runs.
- Any documentation — and "there isn't any" is an acceptable answer. Recovering knowledge is part of the work, not a prerequisite for it.
What you don't need: a solution design, a requirements document, or certainty. Arriving with just a problem is normal here.
If the scope isn't clear yet
Most projects begin life as symptoms — sprawl, a looming deadline, a vague mandate. When scope is fuzzy, the right first step is a fixed-price assessment: it turns symptoms into an inventory, a risk picture, and a sequenced roadmap that's yours regardless of who implements it. And 100% of the focused-tier fee is credited toward any implementation engagement of $25,000 or more signed within 90 days of your readout, so the diagnosis costs nothing extra if you build with us.
If it's not really a project
Some work has no finish line, and forcing it into project shape just manufactures change orders. Continuous, evolving work fits the dedicated consultant model — senior expertise embedded with your team on a recurring basis. And for systems that need ongoing ownership after go-live, the support and enhancement retainer keeps apps, flows, and agents monitored and improving month over month. How We Work compares all three shapes.