How it works
Six stages.Zero slide decks.
We automate only after the workflow is understood. Every build moves through the same six stages, and each one ends in something you can open and check. Below: what happens after the first call, what access we need, how testing and approvals work, how the price is set, and who owns the system afterwards.
Stage 01 · Understand
A first call on yourreal operation.
Thirty minutes on how your business actually works, with the person who would build the system, not a pitch. We map where the hours leak, which workflow should go first, and what should stay human. No technical preparation. You get an honest verdict at the end: build, wait, or not a fit. If the answer is wait, you keep the map.
Ends withan honest verdict and a scoped plan, priced against what this work already costs you.Session map · illustrative
- where the hours go · support 14h, reports 6h, catalog 4h
- kept human · pricing calls, upset customers, partners
- first system named · the support inbox
The verdict: build, wait, or not a fit
honest, scoped, priced against your alternative · yours to make
Needs your call
thirty minutes. your operation. no pitch.
Stage 02 · Design
The agents, the gates,the interface. On paper first.
Before anything is built we define the roles, the workflows between them, the tools and data each one may touch, where approval is required, and whether you need a new control layer or already have one. Scope, price and timeline are fixed in writing here. This is also where we say exactly what access the build needs: scoped, granted by you, revocable by you.
Ends witha written design, a fixed scope and price, and the access list.Design sheet · illustrative
- role · support agent · reads helpdesk, store, policies
- gate · refunds above your threshold · you approve
- interface · your existing dashboard, plus an approvals view
Scope, price and timeline, in writing
one number, agreed before any work starts
Needs your call
nothing is built before it is understood.
Stage 03 · Build
Built for your stack,shown as it runs.
The system is built around your tools and your edge cases, not adapted from a template. Progress shows up as working software you can click, early in the build. You review drafts and flows as they land, so the build is steered by your calls instead of status updates.
Ends witha system running against your real stack, ready to connect and test.Build feed · illustrative
- first review · support agent drafting against real tickets
- second review · approvals view live on your own data
- review call · thresholds moved where you want them
Draft batch ready for your review
your tone, your edge cases · click through it
Needs your call
progress is software you can open, not slides.
Stage 04 · Connect
Connected to the systemsyou already run.
Agents are connected to company knowledge, live data and the systems they act inside, with credentials scoped per integration. If the required access and endpoints are available, the system goes into the build. We verified that before scope was locked, so nothing surfaces halfway through.
Ends withevery integration wired, scoped and logged.Connection log · illustrative
- helpdesk · connected · scope: tickets.read, replies.draft
- store · connected · scope: orders.read
- email · connected · sends held at the gate
Credentials scoped and granted by you
least privilege per integration · revocable any time
Resolved
your accounts. your keys.
Stage 05 · Test
Tested beforeit touches production.
Security, permissions, failure states and approval gates are set and tested against realistic scenarios and real volume. Every write action gets a gate. Every failure gets a loud alert and a paper trail. Nothing meets a customer until it has passed, and no real autonomy is switched on before this stage.
Ends witha system that fails safely and ships nothing without you.The full security postureTest report · illustrative
- permissions · scoped per integration · pass
- failure drill · alert fired, named the step · pass
- volume test · run against real load · pass
Production go-live
tests passed, checklist documented
Needs your call
approval-first. nothing ships without you.
Stage 06 · Launch and hand over
Your environment.Your keys.
The system runs in infrastructure you control. Code, credentials, documentation and runbooks move to you, and we walk your team through operating it. After that, an optional retainer covers tuning and extension. If you stop it, the system keeps running. It is yours.
Ends withfull ownership, documented, with a light retainer if you want one.Transfer log · illustrative
- repository · in your GitHub org since commit one
- credentials · rotated to you · our access revoked
- runbooks and docs · delivered and walked through
The system keeps running
documented, owned, optional retainer if you want it
Resolved
built once. yours for good.
What it costs
Priced after we look.Never before.
There is no price list, and that is not a negotiating tactic. A build is shaped around one operation, so a menu price would be wrong for almost everyone who read it. The number is anchored to what this work already costs you: a hire you were about to make, a team's week going on repeating work, a stack of tools renewing for another year, or an agency retainer that never compounds. You know that number better than we do.
Which is also why the first call is free. If the honest answer is that your alternative is cheaper, you should hear that from us in half an hour rather than find out after an invoice.
The first call
Free. Thirty minutes on your real operation, ending in a verdict: build, wait, or not a fit. You keep the map either way.
The build
Scope and price fixed in writing before any work starts. One number, agreed up front, covering the whole build.
The retainer
Optional and monthly. Stop it whenever you like and the system keeps running, because it was yours from the first commit.
What moves the number
How much operation
One agent taking one job off your desk is a different build from a layer running several departments.
How many systems
Every tool the system reaches has to be wired and tested. Well documented APIs are quick. Stubborn ones are not.
How strange the edges
The rules that live only in your head are the valuable part and the slow part. Mapping them properly is most of the work.
How much is new
Replacing something that already works is faster than designing a process that has never existed.
The timeline
One build,start to keys.
The shape of a build, written as its log. Dates and duration are set on the first call and fixed in the design stage, scoped to your operation, before the build starts.
Build log · illustrative
- step 01 · understand · first call, map drawn, verdict: build
- step 02 · design · scope, gates and access agreed in writing
- step 03 · build · support agent drafting against real tickets
- step 04 · connect · helpdesk, store and email wired, scoped
- step 05 · test · gates set, failure drills, volume test
- step 06 · launch · keys, docs and runbooks handed over
approval-first. nothing ships without you.
FAQ
The practicalquestions.
What happens after the first call?
If the verdict is build, the design stage follows: a written definition of the agents, workflows, gates and interface, with scope, price and timeline fixed before any work starts. If the verdict is wait or not a fit, you keep the map and nothing else happens.
What access does Vulc need?
Only what the design names, scoped per integration and granted by you: read access where an agent reads, draft or write access only where you have decided a write may happen, and admin access to the environment the system is built in, which you own. Every credential is revocable by you at any time, and after handover our access is removed.
How do approvals work during and after the build?
During the build, drafts and flows land in an approvals view for your review as they are made. After launch, anything that touches customers or money stops at a gate with your name on it until you decide it can run on standing approval. You set the thresholds and move them as trust builds.
Who owns the system afterwards?
You do, outright: code, credentials, documentation and runbooks, in a repository under your own organisation from the first commit. It runs in your environment on your accounts. The retainer is optional, and the system keeps running without it.