Skip to content

Instantly share code, notes, and snippets.

@janwirth

janwirth/laboindustria-proposal.md

Last active May 4, 2026 20:39
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save janwirth/95dd53553bd0872b991ee39b2d599724 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save janwirth/95dd53553bd0872b991ee39b2d599724 to your computer and use it in GitHub Desktop.
Download ZIP
LaboIndustria — Website Rebuild Proposal (Elixir/Ash)
Raw
laboindustria-proposal.md

LaboIndustria — Website Rebuild (Requirements Brief & Offer Outline)

Contents

  1. Context
  2. Platform Decision
  3. Scope Tree
  4. Timeline
  5. Component Complexity
  6. Commercials
  7. AS400 Integration — Implementation Notes
  8. Potential AS400 Partners (Italy)
  9. Open Items / Risks
  10. Sources / References

Context

LaboIndustria runs a Joomla site (UI customised only) and the two content managers — Erika Bolletin and Anna Lazzarin — are unhappy with it. Their main complaints: the admin workflow doesn't fit how they actually work, fake bot registrations are a constant nuisance (Joomla 5 dropped its default reCAPTCHA, a likely contributor), and the site is slow and full of 404s/broken links — partly content rot, partly an underpowered vendor host. They want a replacement that behaves like competitors' sites, is simple for both staff and external users, and stays in sync with their AS400 ERP for the product catalogue. They prefer us to host. Target go-live: end of July 2026 (≈2–3 months effort). Offer due end of next week. We're the only vendor in the running so far; budget is small but not disclosed.

Platform Decision

The replacement will not be another Joomla instance. We will build on Elixir + the Ash Framework, with a Phoenix LiveView front-end. Rationale:

  • Ash's declarative resource + policy model maps directly onto the per-section, per-user data-sheet permissions — the part Joomla makes painful.
  • Built-in authorisation primitives reduce custom code for the Visitor / Operator / Admin split.
  • Elixir/OTP gives stable performance on modest hardware (addresses the current host's resource ceiling).
  • LiveView keeps the back-office UX simple and reactive without a separate SPA build.

Scope Tree

  • Pages

    • Home — news cards; latest/front-page article pinned at top, rest reverse-chronological
    • Company — static: history, philosophy, milestones
    • Links — two-level tree (Category → Subcategory): clients, procedures, constraints, regulations; layout mirrors the tree
    • Contacts — static: office references + map
    • Certifications — static: corporate certifications (ISO 9001, etc.)
    • Products — two-level tree (Category → Subcategory); each product has a data sheet whose visibility is permission-gated; no prices anywhere, ever (explicit client rule)

  • Roles

    • Visitor — unauthenticated; sees public sections only
    • Operator — registered + permissioned user
    • Admin / "Master" — manages news, catalogue, users; only role with back-office access

  • Registration & access flow (designed to filter who's actually asking: customer, public authority, collaborator, or competitor — the workflow Erika/Anna currently struggle with)

    1. User submits: first name, last name, email, phone, password
    2. System emails a confirmation link (double opt-in — also primary defence against bot signups)
    3. Admin reviews the request, validates → full account
    4. Admin assigns per-section data-sheet permissions; public sections are on by default

  • Back office (Admin only)

    • News management
      • List / view / edit / delete / create
      • Article template: title, body, publication date, front-page flag (pins to home regardless of date), thumbnail
      • Body supports inline images and embedded external video (YouTube/Vimeo style)
    • Catalogue management
      • Shared data-sheet template, organised in sections; each section is either public or permission-gated per user
      • Data sources are split:
        • From AS400 frontier table (read-only sync): product name, description, category, subcategory
        • Manual entry by Admin: all remaining fields, including the certifications section (list of certification documents per product)
      • Quote-request form at bottom of each data sheet → emails site admin with requester details + message
    • User management — split into two queues, reflecting the two states the admins actually act on
      • Authorised users: full account details + current permissions, editable
      • Pending requests: confirmed-by-email but not yet validated; admin reviews profile and grants section permissions

  • Bot / spam mitigation (implied by the email — must address)

    • CAPTCHA (reCAPTCHA, ALTCHA, or honeypot) on registration + quote form
    • Double opt-in already in the flow
    • Rate limiting on form submissions

Timeline (≈12 weeks, May → end of July 2026)

We use Ash, so there is no separate visual design phase — the requirements gathered with Erika and Anna already describe the UI, and Ash/LiveView generates the screens directly. The AS400 integration is not on this timeline; it runs as a separate hourly track (see Commercials).

  • Phase 1 — Requirements Lock-in (Week 1, May 2026)

    • Walk through the scope tree with Erika & Anna, resolve open questions
    • Confirm the data-sheet section list and which sections are public vs permissioned
    • Sign-off before build begins

  • Phase 2 — Core Build (Weeks 2–6, May → mid June)

    • Ash resources + policies for users, products, news, permissions
    • Auth + registration flow with double opt-in and CAPTCHA
    • Public pages: Home, Company, Links, Contacts, Certifications
    • Product catalogue front-end with permission-gated sections (AS400-sourced fields stubbed as manual-entry until the AS400 track delivers)
    • Quote-request email pipeline

  • Phase 3 — Back Office (Weeks 6–9, mid June → early July)

    • Admin LiveView screens: news CRUD, catalogue CRUD, user authorisation queues
    • Media handling (thumbnails, inline images, embedded video)

  • Phase 4 — Migration (Weeks 9–10, early–mid July)

    • Export news, products, and users from current Joomla install
    • Map and import into the new Ash data model
    • URL-continuity layer (redirects from old Joomla URLs) to preserve SEO and avoid fresh 404s

  • Phase 5 — UAT, Hardening, Launch (Weeks 11–12, mid–end July)

    • Erika & Anna run end-to-end content workflows on staging
    • Load test on production-spec infrastructure
    • DNS cutover, monitoring + backups live, go/no-go review
    • Go-live target: 31 July 2026

  • Post-launch — Maintenance & Support Agreement (rolling)

    • Bug fixes, security patches, minor enhancements, monitoring, backups

Component Complexity

Ash gives us a substantial head start on auth, policies, and CRUD admin — most of the application surface is "configure resources, write policies, generate LiveView screens." The risk is concentrated in one place: the AS400 link.

  • Trivial — leverages Ash/Phoenix defaults almost entirely

    • Static pages (Company, Contacts, Certifications)
    • News CRUD + front-page flag (stock Ash resource + LiveView)
    • Quote-request form → email (Phoenix mailer + a single Ash action)

  • Low — small amount of bespoke work on top of Ash

    • Auth, registration, double opt-in (AshAuthentication covers this; we wire the email template)
    • Visitor / Operator / Admin roles + per-section data-sheet permissions (Ash policies are a natural fit — this is exactly the case Ash is designed for, and it's the part that's hardest in Joomla)
    • Links page two-level tree
    • Products two-level tree + catalogue front-end
    • Bot mitigation (CAPTCHA/honeypot/rate-limit on forms)
    • URL-continuity redirects from the old Joomla paths

  • Low–Medium — Ash helps but design choices matter

    • Data-sheet template with mixed public/permissioned sections (clean Ash resource design needed so section visibility stays declarative rather than scattered through the UI)
    • Back-office LiveView screens, especially the two-queue user management UX (the UX is the work, not the data layer)
    • Media handling: inline images + embedded video in article bodies

  • Medium — straightforward in shape, fiddly in detail

    • Joomla → Ash content migration (news, products, users + permissions); the user-permission mapping is the part most likely to surprise us

  • High — AS400 frontier integration (carved out as a separate hourly package)

    • We do not yet have the schema, access method, refresh cadence, or auth model for the frontier table
    • Possible access paths each carry different risk:
      • Direct DB2 read (cleanest, but needs network access + read user provisioned on their side)
      • Scheduled ETL/CSV drop (simplest to operate, weakest freshness guarantees)
      • REST/SOAP adapter built by the AS400 team (depends entirely on their availability and timeline)
    • Ash itself does not de-risk this — the unknowns sit on the LaboIndustria/AS400 side, not ours
    • To keep the fixed-price scope predictable, AS400 integration is excluded from the €20k fixed price and billed hourly as its own package. The site ships with the AS400-sourced fields editable manually; sync is added when the integration package is delivered (parallel or post-launch)

Commercials

  • Site (fixed-price): minimum €20,000 — covers Phases 1–5: requirements lock-in, core build, back office, migration, UAT/launch. AS400-sourced fields ship as manual-entry until the AS400 package is delivered.
  • AS400 integration (hourly package, separate) — billed on T&M, ringfenced from the fixed scope because the unknowns sit on the LaboIndustria/AS400 side. Starts as soon as schema, access path, and an AS400-side contact are confirmed. Can run in parallel with the site build or after launch. Likely partnered with a specialist (see below).
  • Hosting — included during Phase 5 ramp-up; ongoing hosting billed inside the MSA.
  • Maintenance & Support Agreement — 10–15% of fixed project value / year (€2,000–€3,000/year on the €20k floor); covers patching, monitoring, backups, minor changes; excludes new feature work and the AS400 hourly track.
  • Additional scope (e.g. multi-language, advanced analytics, deeper AS400 write-back) priced separately on T&M.

AS400 Integration — Implementation Notes

Where the AS400 lives. AS400 / IBM i installs are still ~75% on-premise across the industry; for an Italian SME like LaboIndustria the box is almost certainly sitting in their own server room at HQ (or at most colocated at a local provider). Cloud-hosted IBM i exists (IBM Power Virtual Server, partners like Bigblue) but is the exception, not the norm. First thing to confirm with them: where the AS400 is physically located, who has admin access, and whether their network already has a firewall/VPN concentrator we can terminate against.

Our side. We host the new site on Hetzner (probably a CX/CCX box in a German DC). That means the link between our Elixir application and their AS400 has to cross the public internet — so the question is which tunnel and which protocol.

Network options, ranked by what we'd actually pick:

  1. Push model — AS400 → SFTP on Hetzner (recommended for v1). Their AS400 runs a scheduled job (CL/RPG, often already in place for other exports) that drops a CSV or JSON of the product master to an SFTP endpoint we expose on Hetzner. Cadence: nightly, or hourly if they want fresher data. Why this first: zero inbound firewall changes on LaboIndustria's side, no VPN to provision, no IBM i ports exposed. Politically the easiest path through their IT — which matters because we don't control that side.
  2. Site-to-site IPsec VPN, Hetzner ↔ LaboIndustria firewall. Standard pattern for an ongoing direct DB2 read. Tunnel terminates on a router/firewall on their end (most SME firewalls — Fortinet, pfSense, Mikrotik, SonicWall — support IPsec out of the box). On our side, a strongSwan or WireGuard endpoint on the Hetzner host. ACLs lock the tunnel to: DB2 host server port 8471, DRDA port 446 if used, and the IBM i ODBC client's ephemeral return port range (>1024 — needs to be allowed back through). Read-only DB2 user, scoped to a product-master view, credentials rotated.
  3. WireGuard tunnel. Same shape as IPsec but lighter and easier to configure; needs a small Linux jump box on their LAN as the WG peer. Good if their firewall doesn't speak IPsec cleanly.
  4. REST/SOAP adapter on the AS400 itself (IBM Integrated Web Services, or a service the partner builds in RPG). Public endpoint behind mTLS or a reverse proxy; we call it from Elixir over HTTPS. No VPN. Pushes complexity onto the AS400 side — only realistic if we're partnered with Bigblue/ITNow and they own that piece.
  5. SSH tunnel from Hetzner to a jump host on their LAN. Cheap, useful for PoC and during development. Not what we'd run in production.

Recommended sequence: ship v1 with the SFTP-push model (option 1) — it's enough for nightly product master sync, requires the least cooperation from their IT, and gets the site live by end of July. Upgrade to direct DB2 over VPN (option 2) in a follow-up if they want near-real-time freshness.

Elixir side. Three implementation paths matching the network options above:

  • SFTP push: a scheduled Elixir job (Oban) polls the SFTP drop, parses the CSV/JSON, upserts into Ash resources. Stateless, idempotent, easy to retry.
  • Direct DB2: Erlang's built-in :odbc plus the IBM i Access ODBC driver, talking through the VPN. Wrap in an Ash data layer call, run on a schedule. Connection pooling via :poolboy or similar.
  • REST adapter: plain Req/Finch HTTP client, mTLS, parse JSON, upsert into Ash. Simplest code, but only as good as the adapter the AS400 partner builds.

What we need from LaboIndustria before we can size this accurately:

  • Physical location of the AS400 and who their network/firewall admin is
  • Whether a frontier table already exists, or only candidate base tables
  • Sample extract of the product master (10–20 rows is enough)
  • Whether their firewall can terminate IPsec or WireGuard, and what their static public IP is
  • Acceptable sync cadence (nightly is almost certainly fine for a product catalogue)

Potential AS400 Partners (Italy)

For the AS400 hourly track we should pair with a specialist on the IBM i side rather than ramp the skill in-house. Shortlist of Italy-based IBM i / AS400 partners worth approaching:

  • Bigblue (bigblue.it) — IBM i modernisation specialist; automated RPG/COBOL analysis, web and mobile transformation; ~260 Italian enterprises as customers. Strong fit for "expose AS400 data to a web app."
  • ITNow (itnow.it) — AS400 → responsive web, native REST/JSON web services on IBM i, RPG/RPG ILE/SQLRPG. Direct match for the frontier-table-as-API pattern we'd want.
  • ADVICE Information Technology (advice.it) — AS/400–IBM i consulting from design to custom application implementation.
  • Omega Gruppo / Master House (omegagruppo.it) — strategic partner for IBM/AS400 investments, custom software around it.
  • Idonea S.r.l. (idonea.it) — Brescia-based IBM Business Partner; configuration, support, custom software on IBM platforms.
  • Computer Assistance (computer-assistance.it) — IBM partner since 1997, AS/400 + IBM Power maintenance/support focus (more ops than dev).
  • Delta Infor (deltainfor.it) — IBM Power / IBM i infrastructure with security and compliance focus.
  • Record Informatica (recordinformatica.it) — AS/400 / iSeries / IBM i consultancy.

First-call shortlist for this engagement: Bigblue and ITNow — both explicitly position around exposing IBM i data to modern web stacks, which is exactly the frontier-table read we need.

Open Items / Risks

  • AS400 frontier table schema and access method not yet defined — blocks Phase 1 sign-off
  • Budget undisclosed and likely tight — scope discipline matters; €20k is the floor, not a stretch number
  • Migration risk: existing user accounts + permissions need a clean mapping into the new role/permission model
  • 404 history suggests URL continuity work is mandatory if the domain stays the same

Sources / References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment