BASI. Web Services Pilot Start a project

BASI Web Services · Pilot

From first lead to a staged website — with people deciding what matters.

BASI Web Services builds client websites through a structured, personalized, AI-assisted workflow. Humans approve the important decisions; automation handles the repetitive operational work in between. This page documents the first complete run.

See the workflow Pilot result

The challenge

Most website projects don't fail on design. They fail on handoffs.

Scope lives in email threads. Approvals are a "sounds good" that nobody can find later. Intake arrives as attachments, screenshots and voice notes. Every stage needs a manual re-explanation of the last one — and sensitive information ends up in the wrong channel.

  • Fragmented communication. Requirements, questions and decisions scattered across inboxes and chats.
  • Unclear approvals. No durable record of what was accepted, at what price, from which version.
  • Scattered intake. Content and brand material collected piecemeal, with no way to know when it is complete.
  • Repeated manual handoffs. Proposal → onboarding → brief → build re-typed by hand at each step.
  • Too many, or too few, checkpoints. Either everything waits on a person, or nothing does.

The BASI workflow

One lifecycle, nine stages, four human gates.

Every stage writes its state to a single canonical project record, so any teammate — or agent — can pick the project up exactly where it stands. Gates are placed where a decision changes scope, price, the client journey or a security boundary; everything else proceeds without waiting.

  1. Lead

    A prospect completes the BASI project intake. The submission is recorded and synced into the project control record automatically.

    Automated

  2. Qualification

    Fit, scope and budget range are assessed from the intake and reviewed by a person before any proposal is prepared.

    Human gate

  3. Personalized proposal

    A client-specific proposal experience is generated from a structured configuration — scope, options, timeline and terms — and published to a private link.

    Automated · owner-authorized publish

  4. Proposal acceptance

    The client accepts inside the proposal. The acceptance is stored as a durable record bound to the exact proposal version they saw, then verified by a person.

    Human gate

  5. Onboarding

    The accepted proposal unlocks a structured questionnaire in the same experience — resumable in the browser, chunked for reliability, never a channel for sensitive data.

    Automated

  6. Verified questionnaire

    A submission counts only when every part is present and hash-matched. Answers are reconstructed privately, reviewed, and contradictions are listed rather than guessed.

    Automated verification

  7. Production brief

    Client answers become an implementation-ready brief: architecture, conversion goal, integrations, claims that need substantiation, and every launch dependency. The owner approves it.

    Human gate

  8. Internal production

    The site is built in a separate production repository against the brief — design system, copy, SEO, accessibility, forms, and a documented fallback for every unresolved dependency.

    Automated within approved scope

  9. Staging & QA

    Automated gates, browser and accessibility QA, and a private staging deployment. Client review and launch are separate authorizations.

    Human gate · review & launch
Human decision gateAutomated, recorded step

Personalized proposal experience

A proposal that is generated for one client — and remembers exactly what they accepted.

Proposals are not documents attached to an email. Each one is a small, private web experience produced from a structured configuration: the client's context, the recommended option, alternatives, timeline, commercial terms and an acceptance control. Because the configuration is the source, the same system can produce the next client's proposal in minutes without copy-paste drift.

  • Durable acceptance. When the client accepts, the record captures the proposal version, the acceptance identity and a fingerprint of the exact source it was rendered from.
  • Immutable provenance. After acceptance the proposal is frozen to that source. Any material change — scope, price, terms, even the stylesheet — fails the release build until a new version is approved.
  • Human verification. An owner verifies the acceptance record before anything downstream unlocks. "Accepted" always means "accepted and verified".
  • Neutral portal. Proposals live under a shared, non-indexed BASI portal; each client sees only their own experience.

What the system records — illustrative

proposal        v2 · option B · accepted
binding         frozen to source ●●●●●●●
acceptance      VALID · human verified
drift check     no material change
next stage      onboarding · authorization required

Questionnaire architecture

draft           saved in the client's browser · resumable
submission      split into parts + one completion envelope
identity        one stable id per attempt · idempotent retries
verification    COMPLETE only when every part hash-matches
sensitive data  never collected here — by design

Onboarding

Structured intake that knows when it is actually complete.

After acceptance, the same experience opens a guided questionnaire — forty-plus questions across business, audience, services, brand, messaging, trust signals and integrations. It is designed for the way clients really work: in several sittings, on a phone, with interruptions.

  • Browser-safe drafts. Progress is saved locally and restored on return. Nothing is lost to a closed tab.
  • Chunked, idempotent submission. Large questionnaires are sent in parts with a completion envelope, so a network failure retries safely and never produces a half-submission that looks whole.
  • Verified completion. Envelope existence alone is never treated as completion. A private verification step reconstructs the questionnaire and classifies it complete, incomplete or invalid.
  • Secure by boundary. The questionnaire asks for business context only. Anything sensitive belongs to the client's own secure platforms — and the built website enforces the same rule.

Production brief

Answers become an implementation-ready brief — not a guess.

The verified questionnaire is mapped, section by section, into a production brief: objective, audience, services, conversion goal, primary call to action, external intake flow, brand direction, messaging, trust signals, architecture, integrations and launch dependencies. Where the client contradicted themselves, the brief says so. Where a claim needs substantiation — credentials, testimonials, statistics, regulated language — it is flagged, never assumed.

  • Decision log. Each recommendation the owner ratifies or revises is recorded with its rationale, so the build has a single source of truth.
  • Dependencies with fallbacks. Every owner-owned item (an intake link, final pricing, a credential) gets a documented fallback so production never waits on it — and never claims it.
  • Fewer unnecessary approvals. The brief authorizes an entire production phase at once; escalation is reserved for changes to scope, price, journey, security or regulated claims.

Brief sections

Client / projectBusiness objectiveAudienceServicesConversion goalPrimary CTAExternal intake flowBrand directionMessagingTrust signalsArchitectureIntegrationsClaims to verifyLaunch dependenciesDecisions

Automated build + QA

Built in a day. Checked by machines and people before anyone outside sees it.

The pilot site was built as a fully static site on a modern framework and deployed to an edge platform's private staging environment. Every launch-dependent value lives in one configuration file; a missing value activates a documented fallback instead of an unverified claim.

24

Pages built from the approved sitemap, including resources and a printable checklist

277

Automated gates per build — content rules, metadata, links, forms, structured data, function contracts

0

Accessibility violations across every page at desktop, tablet and phone widths

<100 KB

Home-page transfer, no external fonts or scripts beyond form protection

Pilot staging website home page on desktop: a cream hero with the headline 'Tax preparation that's clear, organized, and easy to complete from anywhere' and two buttons.
Pilot build · staging · desktop. Not the client's production website.
The same pilot home page on a phone, with a Menu button and stacked buttons.
Pilot build · staging · phone.
Pilot staging 'How it works' page with a five-step process and an intake button.
Process page with structured-data steps and the intake handoff.

What QA checks on every build

  • Prohibited or unverified claims (credentials, guarantees, testimonials) cannot ship.
  • No file uploads or sensitive fields exist anywhere on the site.
  • Responsive layouts, keyboard navigation, skip links, heading order and contrast.
  • Form protection: bot challenge verified server-side, honeypot, field allow-list, refusal of anything that looks like an SSN or card number.
  • Preview forms say plainly that nothing was delivered; provider activation fails closed until real identifiers exist.
  • Metadata, canonical URLs, structured data, sitemap and robots directives match the environment.

Pilot result

A complete staging website, produced from the approved brief.

The pilot moved a real business from intake to a reviewable staging site in two days of calendar time, with every stage recorded in the canonical project record and every human decision captured where it was made. No production launch was performed: the run was designed as a test of the system, and the client's existing website was left untouched throughout.

Test run complete

Lead to staged build, end to end — with four human decisions and no manual re-typing between stages.

  • Personalized proposal published, accepted and verified with frozen provenance.
  • Structured questionnaire completed, chunk-verified and reconstructed privately.
  • Production brief approved; decisions logged; dependencies given fallbacks.
  • Static site built, 277 automated gates green, accessibility clean, staged privately with preview-only forms.
  • Launch, DNS and client-review delivery intentionally left as separate authorizations.

What BASI learned

Seven improvements the pilot forced — now part of the standard.

  • Chunked intake for large submissions

    The first real questionnaire exceeded the storage record limit. Submissions are now split into parts with a completion envelope and idempotent retries — and a draft is never lost.

  • Immutable proposal provenance

    Acceptance freezes the proposal to its exact source. The site can be re-released for other reasons while the accepted proposal stays byte-identical, and any material drift fails closed.

  • Fewer human gates

    One authorization now covers a whole phase. Escalation is reserved for scope, price, journey, security boundaries, regulated claims and irreversible external actions.

  • Honest preview forms

    A staging form that "succeeds" without delivering anything is misleading. Preview mode now states that the form passed validation but nothing was sent — and can never land on a "message received" page.

  • Fail-closed provider activation

    Placeholder identifiers are gone. A CRM or email provider activates only when every required id is present and well-formed; otherwise submissions are refused rather than faked.

  • Existing-domain collision checks

    Before any hosting is created, the system records what already serves the client's domain. Launch is planned as a controlled cutover with a rollback destination, never as attaching an unused domain.

  • Canonical-state recovery

    Because every stage writes to one project record with exact-cell updates and read-back verification, an interrupted agent run resumes from recorded state instead of from memory.

The system ahead

The pilot proved the front half. The same discipline extends to the rest.

  1. ProposalsPersonalized, versioned, durably accepted
  2. OnboardingStructured, resumable, verified
  3. ProductionBrief-driven build with automated gates
  4. Client reviewPrivate preview, one consolidated round
  5. Final approvalRecorded against the reviewed version
  6. LaunchPreflight, controlled cutover, rollback
  7. MaintenanceRecurring care, content and conversion work

Start a project

Your website, delivered through a process you can see.

Tell BASI about your business, goals and website needs. Qualified projects receive a personalized proposal — and from there, the workflow on this page.

Start your website project Review the workflow again