FORTOXA Discuss your workflow

For small teams with repetitive work.

Less manual work.
Same sign-off.

Fortoxa builds custom AI workflows, release checks and internal apps for small teams. The repetitive steps run on your own systems; a named person still approves anything that matters.

  • Start with one workflow
  • Your repository, your code
  • A person signs off
board / T-114 · vendor onboarding sample run

Agent run — vendor onboarding

awaiting review
  1. Read the signed brief1 page
  2. Scoped tool access, read-only4 tools
  3. Ran the card's checks11 pass
  4. Check 12 failed — release heldneeds input
gate.pyverify → publish
# the card names the checks
def verify(card, run):
    for check in card.checks:
        if not check.run(run).passed:
            hold(reason="check 12 failed")

Human approval required

A failed check stops the release. Only a person clears a held gate.

Agentic workflows Security workflows Agentic web apps Custom builds, no templates Built, gated, handed over One enquiry · one card · one build
01 / What we build

Start with the work.
Choose the right tool.

For small teams managing enquiries, shipping software or building internal tools. Pick the problem closest to yours.

01 / General workflows

Less copying. Fewer manual handoffs.

AI handles the repetitive steps — sorting enquiries, preparing documents — and a person approves anything that leaves the team.

  • Enquiry sorting and draft briefs
  • Routine reporting and document preparation
  • Approval before an external action

Start with one repeatable task.

Discuss your workflow →
02 / Security workflows

Catch release problems earlier.

Automated checks stop a release when something is wrong, with the finding and its evidence in front of a named reviewer.

  • Dependency and container checks
  • Readable findings with supporting evidence
  • Clear approval and exception handling

Defined checks, not a compliance certificate.

Discuss your workflow →
03 / Agentic web apps

Give your team a usable AI tool.

A small internal app where your team assigns work to an agent and reviews the result before it goes further.

  • Task submission and progress views
  • Review steps and run history
  • Defined access and usage limits

The interface and code belong to you.

Discuss your workflow →

Your code

Development in your repository, with an agreed handover.

Your approvals

Decide who can approve important actions before the build begins.

Clear scope

Agree the work, acceptance checks and estimate before implementation.

02 / See the gate work

A failed check
stops the release.

Watch an illustrative change move through the checks. When one fails, the release holds until a named reviewer approves it.

Interactive simulation — the build, the checks, the finding and the reviewer are scripted. Nothing is built or tested in your browser.

  1. Checks run
  2. Release held
  3. A person approves
  4. Release continues

Not started.

Automated checks

  • Build and type check Waiting
  • Accessibility rules Waiting
  • Contrast on two buttons Waiting

Release gate

Waiting for the checks.

Illustrative example: the change, the finding and the reviewer name are not a client result.

That’s the gate. Want it on your release process?

We build the same check-and-approve step into your delivery workflow, with the checks agreed before the build starts.

Discuss your workflow
03 / How we work

A clear path from idea
to handover.

Know what happens next, what you receive and where your approval is needed.

  1. 01 / Define

    Agree the outcome.

    Map one task, the systems involved and the limits. Agree the scope and estimate before work starts.

    You receive a written brief.
  2. 02 / Build & review

    See the work develop.

    Review the implementation in your repository. Test the agreed behaviour, including what happens when something fails.

    You receive code and test evidence.
  3. 03 / Launch & hand over

    Keep control after launch.

    Approve the release with a rollback plan. Document how it runs, what remains open and who maintains it.

    You receive release and handover notes.
04 / Workflow illustrations

Workflows,
illustrated the way we build.

Three workflows, each focused on a different problem. The first is our own enquiry intake, running as a working build in our tooling — this review copy does not include its backend. The second and third are illustrations only: no working build of them exists here. All three animations show the workflow shape, and none is a recording of a client system.

General workflows

Enquiry to structured brief

Internal build — our own enquiry intake, whose backend is not part of this review copy; the animation illustrates its workflow and is not a recording of a client system.

Turning an incoming request into a stored enquiry and a brief.

Explore the workflow
Input
A request and its supporting context.
Output
The brief you wrote, stored with the enquiry, and a record of the steps taken.
Human review
A person reads the enquiry and replies by email.
Discuss your workflow →
Security workflows

Checks before release

Illustration — the animation shows the workflow shape; it is not a recording and not a working build.

A defined set of read-only checks, with findings organised for review.

Explore the workflow
Input
An authorised website or repository within an agreed scope.
Output
A prioritised report with the evidence behind each finding.
Human review
Review the findings and decide what must be fixed before release.
Discuss your workflow →
Agentic web apps

An interface for agent work

Illustration — the animation shows the workflow shape; it is not a recording and not a working build.

Assigning a task and following its progress through an application.

Explore the workflow
Input
A task, allowed tools and clear limits.
Output
A visible activity history that can be reviewed after the run.
Human review
Review the proposed action at defined approval points.
Discuss your workflow →

Also exploring a website rebuild? View the two independent website concepts →

05 / Practical questions

Before you start.

Who is this for?

Small teams with a repeatable task, a software release process to improve or an internal tool to build. Start with one workflow and a clear owner.

Who owns the code?

You do. The implementation goes into your repository, with the agreed documentation and handover notes.

Can it run on our infrastructure?

Self-hosting is considered during scoping. If a feature needs an external model or service, that dependency and its costs should be agreed before implementation.

What happens when an automated step fails?

The workflow should stop at a defined point, record the failure and hand it to the named reviewer. The expected behaviour is agreed and tested as part of the scope.

How are price and timing decided?

They depend on the workflow, integrations and acceptance checks. Scope, estimate and schedule are agreed before development; no fixed package is quoted here.

What about ongoing costs and support?

Hosting, model usage, maintenance and support need to be agreed in the proposal. Code ownership does not automatically include ongoing hosting or maintenance.

Is an architecture review a security certification?

It scopes a workflow or release process. It is not a compliance assessment and does not provide a certificate.

06 / Plan the project

Start with one
worthwhile problem.

An architecture review maps the outcome, the systems involved and the decisions that need a person. Bring the task, the systems and who signs off; the enquiry form is where you set it out.

What to put in your brief

  1. The task and what success looks like.
  2. The tools, data and systems it touches.
  3. Who reviews and approves the result.
  4. The timeline and constraints that matter.

We read it and reply by email.

07 / Enquire

Tell us what should
run itself.

Five fields. Your enquiry goes to the studio workflow and we reply by email. No cost and no commitment to enquire.

See the release gate

This sends your enquiry to the studio’s workflow. Nothing is stored in this browser and no cookie is used.

Prefer email?

sales@fortoxa.com

Write to us there and we will reply by email.

What happens next

  1. You send the form or the email.
  2. We reply with questions, or with a short written plan.
  3. You decide whether to go ahead.

We do not publish fixed prices or delivery dates here, because both depend on the work.

Discuss your workflow

What would you like
to make work better?

Start with the outcome, the systems involved and the person who approves the work. The enquiry form takes all five fields, and we reply by email.