INSIDE A MARAPONE HANDOVER: WHAT YOU GET ON DAY 14.

Day 14, 9am: a single Git repo lands in your account

The handover is a Git repository — pushed to whichever Git host you already use (GitHub, GitLab, Bitbucket, or your self-hosted Gitea). One repo, one commit history, one README that reads top-to-bottom.

The folder structure is opinionated and boring on purpose:

your-marapone-build/
├── README.md
├── LICENSE
├── docker-compose.yml
├── .env.example
├── models/
├── data/
├── src/
└── runbooks/

Eight top-level entries. Anything else lives below those. The point of the structure is that an IT generalist who's never seen the system can find anything within thirty seconds.

README.md — the one document that matters

Not a marketing page. The README is roughly 200 lines and answers exactly:

• What this system does, in one paragraph.
• How to install it from scratch, in numbered steps.
• How to ingest a new project's documents.
• Where the runbooks live for everything else.
• Who to call if something is on fire.

If your IT lead can't be productive within 30 minutes of reading the README, we wrote a bad README. We rewrite until they can.

docker-compose.yml — the entire system in one file

The full stack starts with one command: docker compose up. The compose file declares every service: the inference server, the API, the Postgres database, the vector store, the UI, the reverse proxy. No Kubernetes, no Helm charts, no operator pattern. Boring containers. By design.

If you outgrow Docker Compose, swapping to Kubernetes is documented in a runbook, but you almost certainly won't need it.

models/ — your weights, on your disk

The base open-weight models (Llama 3.1, Qwen 2.5) plus any fine-tunes we trained for your shop. Every fine-tune ships with:

• The training script that produced it.
• The dataset that trained it (or instructions to regenerate it from your data).
• An eval set with expected outputs.
• A version tag and a changelog.

If a future model release outperforms the one you're running, you can swap it without losing your customizations.

data/ — segregated by project, by default

Every project ingested into the system gets its own subfolder. Documents stay in their original format alongside the parsed text and embeddings. If you ever need to delete a project, it's one folder removal — not a database migration.

src/ — three subdirectories, no surprises

src/api/ — the FastAPI service. Routers per workflow (rfi.py, daily_log.py, change_order.py). Pydantic models for every request/response. Pytest suite for every router.

src/ingest/ — the OCR and chunking pipeline. One module per source type (Procore, Bluebeam, SharePoint, email). Clean interfaces; you can add a new source in a few hundred lines.

src/ui/ — the Next.js app. Standard app-router layout. Tailwind already configured. If you have a frontend developer, they'll feel at home immediately.

runbooks/ — the operations binder, in Markdown

Five files that cover the operational lifecycle:

1. 01_install.md — fresh install, hardware to running system.
2. 02_ingest_new_project.md — add a new project's drawings, RFIs, and emails.
3. 03_retrain_classifier.md — improve the RFI classifier on new examples.
4. 04_backup_restore.md — backup strategy and restore drill.
5. 05_incident_playbook.md — what to do when something is on fire.

Every runbook is tested by us before handover. If a step is wrong, we fix the docs.

Day 14, 2pm: a 60-minute walkthrough call

We screen-share the running system and talk through the repo with your team. Your IT lead, your PE champion, and (if you want) your CIO sit in. We answer every "wait, what's that?" question in the call. By the end, the team can independently take a step they didn't know they could.

Then we leave you alone, with a Slack channel open in case you need us. That's the whole handover.