Naughty Bean Consulting
Sheet 02 Services
Sheet 02 Specification Rev C

Scope of works

The specification for what we build, how we build it, and what we leave out. Read it the way you would read a drawing: the clauses are the contract, the register is the proof.

We are a software engineering studio. Everything below is something we have shipped for ourselves or for a client, and every clause links to a sheet in the drawing register where you can see it running.

Web applications

Clause 1.0
  1. 1.1

    Portals and storefronts

    Customer-facing web apps, server-rendered with HTMX and Alpine.js so they load fast on a phone on a bad connection and still feel instant. Ordering, booking, accounts, self-service.

  2. 1.2

    Back-office systems

    Order management, stock, billing, reporting, approvals, and the role-based admin that every business needs and nobody budgets for. We have built point of sale, payroll and operations portals from scratch, so we know where the bodies are buried.

  3. 1.3

    Content-managed sites

    Marketing sites and e-commerce where you edit pages, menus, products and theme colours yourself. No developer on the critical path for a price change.

  4. 1.4

    APIs

    Headless REST APIs with django-ninja or NestJS when a separate front end, a mobile app or a partner needs to talk to the system. Documented with OpenAPI, versioned, authenticated with keys or sessions.

    DjangoPostgreSQLHTMXAlpine.jsTailwindNestJSReactNext.js

Mobile apps

Clause 2.0
  1. 2.1

    Installable progressive web apps

    Home-screen icon, full-screen, service worker, one codebase. Our POS terminal, barista app and customer ordering app all ship this way and behave like native apps on the devices people actually own.

  2. 2.2

    Field and counter tools

    Interfaces designed for one hand, poor light and a hurry: tills, clock-in stations, checklists with photo evidence, stock-take flows. Big targets, few taps, obvious state.

  3. 2.3

    Native builds

    When the brief needs hardware access or app-store distribution that a PWA cannot give, we scope a native iOS and Android build on top of the same API. We will tell you plainly if you do not need one.

    PWAService workersWeb pushiOSAndroid

SaaS platforms

Clause 3.0
  1. 3.1

    Multi-tenant architecture

    One PostgreSQL schema per tenant where isolation matters most, or row-level security in a shared schema where scale matters more. We have shipped both and can explain the trade-off in ten minutes.

  2. 3.2

    Billing and entitlements

    Flat plans, commission models, usage limits and add-on modules, decided at runtime by an entitlement engine so a plan change is configuration, not a deployment. Recurring billing via Paystack or Stripe.

  3. 3.3

    Custom domains and branding

    Tenants on their own subdomain or their own domain, with certificates issued automatically when they point DNS at you. Per-tenant logos, colours and e-mail templates.

  4. 3.4

    Access and audit

    Role-based access per organisation, invitations, MFA, session revocation and append-only audit trails. The admin console the founder needs on day one, not in year two.

    django-tenantsRow-level securityPaystackStripeAutomated TLS

Integrations

Clause 4.0
  1. 4.1

    Payments

    Yoco, PayFast, Stripe, Paystack, iKhokha and Stitch. Webhooks that survive retries, reconciliation, refunds, and per-country routing when one platform serves many markets.

  2. 4.2

    Messaging

    Twilio WhatsApp Business API with approved templates, signed webhooks and inbound automation. Transactional e-mail through Resend, SendGrid or Mailgun with proper domain authentication.

  3. 4.3

    Accounting and payroll

    Xero sales exports that tie out to the cent, Sage Accounting timesheets, SARS-compliant VAT, bank EFT file formats for the major South African banks, EMP201 and IRP5 outputs.

  4. 4.4

    Logistics and hardware

    Courier APIs for live rates and tracking, espresso-machine telemetry, water-quality sensors and biometric clock-in terminals over their LAN protocols. If it has an API we will integrate it; if it does not, we will reverse-engineer it and document what we find.

    YocoPayFastStripePaystackiKhokhaStitchTwilioXeroSageThe Courier GuyFlow CoffeeWaterTDSHikvision ISAPIGoogle Places

Cloud & delivery

Clause 5.0
  1. 5.1

    AWS, defined in code

    ECS, RDS, WAF and multi-account landing zones with Control Tower, all in CDK. Separate accounts per environment and, for enterprise customers, per tenant. Deploys through GitHub Actions with OIDC, no long-lived keys.

  2. 5.2

    Right-sized hosting

    A single well-kept VM with nginx, systemd and PostgreSQL is a legitimate architecture for a great many businesses. We will not sell you Kubernetes for a coffee shop.

  3. 5.3

    Pipelines and promotion

    CI that runs the tests, scans dependencies and secrets, builds one image and promotes that same verified image from development through QA and staging to production.

  4. 5.4

    Monitoring and runbooks

    Sentry, CloudWatch, uptime checks and a post-deploy gate that confirms the thing actually works before the pipeline goes green. A runbook you can follow at 2 a.m.

    AWSCDKECSRDSControl TowerGitHub ActionsSentrynginxsystemd

Security

Clause 6.0
  1. 6.1

    Penetration-test remediation

    From a findings report to a closed-out evidence pack: triage, fixes, regression tests, and the management summary the auditor asks for.

  2. 6.2

    Tenant isolation

    Schema separation, PostgreSQL row-level security, and access checks that run before any data is touched. Tested with a harness that tries to read across tenants and must fail.

  3. 6.3

    Hardening

    MFA, session management and revocation, WAF rules, rate limiting, dependency and secret scanning in CI, and POPIA-aware handling of personal information.

  4. 6.4

    Scutiva

    Our open-source, agentless posture and SBOM tool for Linux fleets. Self-hosted, SSH-based, nothing leaves your network. Sheet P-08.

    OWASPMFARow-level securityAudit trailsPOPIASBOM

AI features

Clause 7.0
  1. 7.1

    Document extraction

    Bills, leases, invoices and statements read into structured data, validated against the printed totals so a model cannot quietly drop a digit or a minus sign.

  2. 7.2

    Conversational intake

    WhatsApp orders and support requests parsed into orders and tickets, with a human confirming anything the model is unsure about.

  3. 7.3

    Plainly

    We call model APIs directly through OpenRouter or the provider. No agent frameworks, no vector database unless retrieval is the actual problem, and no AI feature that does not have a measurable job.

    OpenRouterClaudeFastAPIHuman in the loop

Exclusions

Things we do not do
  1. WordPress page builders, theme customisation and plugin archaeology.
  2. Strategy decks with no implementation attached.
  3. "Quick MVPs" we would not be willing to run in production ourselves.
  4. Blockchain.

Commercial terms

How we charge
RefModelWhen it fitsBasis
C1Fixed-price buildA defined product with a scope we can draw up at Rev B. Most builds on the register started this way.Fixed quote · milestones · Rand
C2RetainerRunning, monitoring and improving a live system month to month. Priority response, a standing backlog, no re-quoting for small work.Monthly · agreed hours · rolling
C3Time and materialsDiscovery, audits, penetration-test remediation and anything genuinely open-ended. Estimated up front, billed on actuals, reported weekly.Day rate · weekly report
Request for quotation

Tell us what to build.

A web app, a mobile app, a platform, an integration nobody else wants to touch. Send the brief, we reply with questions, a scope and a price.