Skip to content
Alphacroft

The process

Exactly how an engagement actually runs.

Most firms describe their process in adjectives. Here is ours in specifics: what happens, when, what you see while it happens, and what you own at the end. Hold us to any line on this page.

01 · First conversation

Thirty minutes. No pitch deck.

What we’ll ask you

  • What does the business do, and where does it hurt right now?
  • How is this handled today: walk us through an actual example.
  • What would 'this worked' look like in six months, in numbers if possible?
  • Who decides, who uses it daily, and who can kill it?
  • What's the honest budget territory and timeline pressure?

What you’ll know by the end

  • The rough shape of a solution, or the news that you don't need one built.
  • A cost band with the assumptions that drive it.
  • Whether we're the right fit, including a referral elsewhere if we're not.
  • Exactly what happens next, with dates.

If the call concludes you don’t need custom software, we say so and part as friends. That call costs you thirty minutes; the alternative costs you a budget.

02 · Scoping & proposal

A proposal you can hold us to.

Every proposal is a numbered document with a validity window, and every claim in it survives into the project as acceptance criteria.

§1

Scope sections

What we're building, described concretely enough to test against, each with its own acceptance criteria.

§2

Investment table

Fixed line items mapping to scope sections. The invoice will match this table, line for line.

§3

Timeline with phases

Duration bands per phase and the demo rhythm you can expect.

§4

Assumptions & exclusions

The honesty section: what the price assumes, and what is deliberately out. Fewer surprises are engineered here than anywhere else.

§5

Acceptance criteria

Copied verbatim into your project's milestones: the proposal's promises become the portal's checkboxes.

§6

Validity window

Prices are real, so they have a date. No fake urgency; just an honest shelf life.

03 · Build rhythm

Working software, every single week.

Every week of build ends the same way: an update in your portal with what shipped, what’s next, and what we need from you, plus a staging link where you can click the actual software. Most weeks include a short demo call; every week includes the written record.

Scope changes happen on real projects, and the process treats them as first-class: a change is described, priced, and scheduled before it’s built, and you approve it in the portal where the decision is recorded. The alternative, changes absorbed silently and invoiced angrily, is how projects end up in court.

The portal is not a status theater. It shows the same milestone data we manage the project by. When something is late, you see it the moment we do, with what we’re doing about it. A vendor who can’t show you a bad week honestly will eventually hide a bad month.

alphacroft.com/portal

Your workspace

  • Dashboard
  • Projects
  • Approvals
  • Invoices
  • Files
  • Support

Customer portal rebuild

Milestone 3 of 5 · next demo Friday

In progress
Discovery & scopeAccepted
Design system & key screensAccepted
Core build: orders moduleIn progress
Reporting & adminUpcoming

Latest update · Friday

Orders module is on staging. Demo link inside. One decision needed from you on the refund flow (2-minute read).

The portal every Alphacroft client gets, rendered from the real product, not a mockup.

04 · Launch & handover

Ownership, itemized.

'You own the code' is easy to say. This is the checklist that makes it true, published so you can hold any vendor to it, including us.

PACK.01

Repository transfer

The code moves to your organization's account. Transferred, not shared.

PACK.02

Infrastructure & credentials

Cloud accounts in your name, every login and API key inventoried with rotation notes.

PACK.03

Architecture documentation

An overview a new engineer can orient from in an afternoon.

PACK.04

Runbook

Deploys, rollbacks, and backups, including a restore we actually performed, with timings.

PACK.05

Decision log

Why we chose what we chose. The 'whys' are what the next team really needs.

PACK.06

Training session

Recorded walkthrough for your team, or your next vendor. No hostage dynamics.

The handover standard: a competent engineer who has never met us should be able to deploy a change within a day using only the pack. Then a 90-day warranty backs the work itself.

05 · After launch

Kept healthy, or handed over clean.

Three support plans with instrumented SLAs, or no plan at all, because the handover pack makes 'goodbye' a real option. Most clients honestly fit Standard.

Support plan

Essential

Stable systems with occasional needs

  • Business-hours response
  • Uptime monitoring
  • Security patching
  • 4 improvement hours / month

Support plan

Standard

Systems your operations depend on

  • Faster response targets
  • Monitoring + patching
  • Quarterly health report
  • 10 improvement hours / month

Support plan

Priority

Systems where downtime is revenue

  • Same-day targets
  • Out-of-hours cover, critical severity
  • Quarterly health report
  • 20 improvement hours / month

Exact response targets and prices are stated in every proposal. SLA performance is tracked in the same portal you raise tickets in. More on support →

06 · Commercial principles

The fine print, in large print.

Fixed scope, quoted in writing

With the assumptions listed, so you can see exactly what moves the number.

Changes priced before work

A change order states cost and schedule impact before anyone builds it. No surprises invoiced later.

You own everything

Code, infrastructure, credentials, documentation, from day one, contractually.

No lock-in, ever

Leave with your code at any time. The handover pack is rehearsed, not theoretical.

Invoices match the proposal

Line items map to scope sections. Your accountant will not need a meeting with ours.

We'll say no

To scope that doesn't serve you, to AI that won't pay off, to projects we're wrong for.

07 · The hard questions

Asked by skeptics, answered in full.

Why should we trust a new company?
You shouldn't, on our word alone. That's why the engagement structure does the trusting for you: fixed scope in writing, weekly demos of working software, a live portal showing real status, staged payments tied to accepted milestones, and a handover pack that means you could walk away at any point with everything. Every one of those mechanisms protects you regardless of how much you trust us. Established firms ask for faith; we've tried to make faith unnecessary.
What if we're unhappy mid-project?
Say so. The weekly demo exists to surface this early, when correcting course is cheap. If it's deeper than a course-correct: work pauses at the current milestone, you pay only for milestones delivered and accepted, and you receive everything built so far with documentation. It's in the contract. An exit that's fair on paper is also excellent motivation for us to never need it.
What happens to our data?
It stays yours, processed under a data-processing agreement your counsel can review. During the engagement we access the minimum needed, in environments we document; at close, our access is revoked and we confirm deletion of working copies. Financial records we must retain by law are the only exception, and the privacy policy lists every processor we use.
How fast can you start?
First conversation within a business day of your inquiry. Discovery typically starts within one to two weeks. Build start depends on scope and current commitments, and we'll tell you the real date rather than an optimistic one, because the schedule is the first promise we make and we intend to keep the habit.
We have a small budget. Is that a problem?
Small budgets need sharper scoping, not apologies. Tell us the number honestly and we'll tell you what it buys: often a leaner version of what you asked for that still solves the core problem, sometimes advice to spend it differently, occasionally 'wait and save'. What we won't do is take a budget we know is insufficient and discover it together later.
Do you work on-site?
We work remote-first with deliberate on-site moments where they earn their cost: discovery immersion, kickoffs, launch days. The portal keeps remote from meaning invisible: you see more of a remote Alphacroft project than most clients see of an on-site one.
Do you subcontract the work?
No. The people you meet are the people who build. If we ever need a specialist (say, a niche compliance reviewer), it's named, disclosed, and under our contract and our standards, never anonymous outsourcing.
What does the 90-day warranty actually cover?
Defects: anything in the delivered scope that doesn't behave as the acceptance criteria said it should, fixed free, at our initiative when monitoring catches it before you do. It doesn't cover new features or scope changes; those are honest change orders. The line between the two is the acceptance criteria we both signed, which is why we write them so carefully.
Will you work with our existing systems and vendors?
Yes, most real projects are brownfield. We integrate with what earns its place, replace what doesn't (with reasons in writing), and coordinate with your other vendors like adults. The audit that starts most engagements maps exactly this.
Will you sign our NDA?
Yes, before you tell us anything sensitive. It's a normal part of the first week. We'll also send ours if you don't have one handy.

Test the process on a real conversation.

The first call is thirty minutes and costs nothing but the calendar slot. You’ll leave with a shape, a number band, and an honest fit assessment.

Start the conversation