What Daedalus actually does

1.1 Customers & vehicles

One record per customer with every vehicle they own, joined by VIN. When a truck gets sold, the next owner inherits the repair history you built — they see the cat replacement you did three years ago, the timing-belt service from last winter, the brake job last month. History travels with the vehicle, not the customer.

• Customer types: individual or commercial; corporate fleet accounts track an account contact + billing contact separately
• Multi-phone, primary + alt; email; physical address; tax-exempt flag with certificate ID
• VIN-keyed vehicle records: make / model / year / engine / trim / colour / license plate / odometer
• "Custom Vehicle" path for kit cars, antiques, non-US-market imports — flagged so analytics can exclude them
• CSV import from whatever software you're leaving — customers + vehicles in one pass
• Demo-data button loads 5 customers / 7 vehicles / 3 ROs so you can poke around before committing real data

1.2 Repair Orders

Every RO moves through four primary stages — Draft → Estimate → RO → Invoice — with Paid as the closure and Voided as the audit-preserving cancellation. RO numbers are per-shop: your sequence starts at RO-1001 regardless of what other shops on the platform are doing.

• Per-RO notes (pinned + chronological), work assignments, diagnostic-import attachments (scan-tool exports)
• Photos: before / after attachments per line item
• Supplemental estimates: customer can approve a new amount mid-job; original kept for audit

1.3 Estimates & invoices

Build an estimate with line items — parts, labor, sublet, fees. Send it for the customer's approval (email or SMS with a magic-link page; no account required). Approved estimates turn into ROs in one click. Invoices carry time, parts, labor, tax — all carried through automatically.

• Line items track cost + markup-percentage separately from the price the customer sees — you see your real margin without re-doing the math
• Parts catalog (WorldPac / NAPA / generic) with on-the-fly search; markup defaults configurable per category — see Chapter 7 for live PartsTech pricing
• Per-line tax categories + a customer-supplied-parts waiver flag for the lines a customer brings their own part for
• Tax + labor rates per shop, multiple jurisdictions supported
• Templates: save a common job (e.g. "front brake service") with pre-filled line items, pull it into any future estimate
• Magic-link approval URLs are single-use, time-boxed, and tied to a specific RO — they don't expose anything else

1.4 Payments

Record payments against an invoice — cash, check, card, ACH. Partial payments supported. When a payment closes out the balance, the RO state advances to Paid automatically. Each payment is timestamped, attributed to who took it, and tied to the invoice + RO for audit.

1.5 Appointments & bays

Schedule customers for a specific bay on a specific day. Mobile shops skip the bay assignment and use a location text + GPS coordinates instead. Each appointment links to the customer + vehicle; reminders go out via the communications channel the customer prefers.

• Bay-aware — define your bays, get a visual schedule (see §8.5)
• Mobile-shop mode — location text + lat/lon, no bay column; the route optimizer (§4.2) sequences the day
• SMS / email reminders, configurable lead time

1.6 Inspections & QC

Multi-point inspection sheets attached to an RO. Pre-built templates for common safety / brake / suspension sweeps; you can also define your own. Each item gets pass / advisory / fail with optional photos and tech notes. Failed items can feed back into a follow-up estimate with one click; declined items can feed the win-back engine (§5.3).

• Sheets are sealed on completion so the record of what was inspected, and when, can't be quietly edited after the fact
• QC checklist — a final quality-control pass before the car goes back to the customer, recorded on the RO's workflow section
• Comeback tracking — when a car comes back for the same concern, it's linked to the original RO so your comeback rate shows up honestly in the KPIs (§6.3)

1.7 Customer communications

Every text, email, voicemail transcript, and in-person conversation gets logged on the customer or RO timeline. SMS goes through Twilio; email through Postmark or SMTP. Inbound replies route back to the same thread automatically (so a customer texting "yes" to an approval lands on the right RO).

• Per-shop sender identity: emails go from [email protected], not from us
• Bounce-suppression: a hard-bounced address is flagged so you don't keep emailing into the void
• Twilio inbound SMS is signature-verified — won't accept a spoofed approval
• Consent + opt-out are enforced on every send — see §12.3 for the communications-law rules Daedalus applies automatically

1.8 Customer portal

Your customers sign in at daedalusautomotive.app and see your shop's face, not ours. Their dashboard shows the Logbook for every vehicle they've ever brought you, current and historical ROs, estimates awaiting approval, and outstanding invoices. A Powered by Daedalus byline lives in the footer — understated, where it belongs.

• Per-shop accent colour: brand the portal in your shop's identity
• Logbook view per vehicle (history travels with VIN)
• Approve estimates inline, pay invoices online, request appointments
• Magic-link sign-in (no password required for low-touch customers); password optional for repeat users

2.1 Ask Daedalus AI

A diagnostic Q&A surface available from any page — the always-on assistant orb, plus a Chat tab for free-form questions. Ask about a DTC, a symptom, a procedure, a part — answers come back grounded in a curated knowledge base of 210+ entries (P-code symptom guides, FaultID registry, OEM module catalog, actuator presets) and NHTSA recall/TSB data for the specific vehicle you're working on.

The assistant can also act on your data when you ask — pulling live KPIs, looking up ROs and customers, and drafting create-customer / open-RO actions (it confirms before making more than one change at once). Paste raw intake notes into Chat and it will parse the customer, vehicle, and three C's into a new RO.

Refuses to help with emissions defeat, safety-interlock bypass, and odometer rollback. Answers questions about aftermarket modifications and high-voltage work (with safety procedure prepended).

2.2 Summarize AI

Sparkle buttons next to the Complaint / Cause / Correction / Note fields on every RO. Type rough notes the way a tech scribbles them; click Summarize; get a shop-voice rewrite ready to paste into the field. Designed to be terse — 1-2 sentences for complaint and note, 1-2 for cause, 2-3 for correction.

Receives the RO context (vehicle, current field values, active DTCs) so it doesn't strip useful detail just to be short. Never adds diagnosis or speculation to the complaint — it only rewrites what the customer actually said.

2.3 Explain — for customer comms AI

The customer-facing counterpart to Summarize. Summarize (§2.2) lives on the working RO fields and polishes tech-to-tech writing. Explain lives on customer-facing surfaces and rewrites tech-language into plain English the customer will understand — without losing the technical truth.

Where it appears:

• Notify-customer-ready modal — when you tap "Notify ready" the message composer includes an ✨ Explain button. Paste any tech- language cause / correction text in, click Explain, and the message is rewritten for the customer.
• Future customer-comm composers (estimate-approval email, invoice cover note, SMS templates) will attach the same button.

2.4 Cross-shop diagnostic intel AI

When you're looking at a DTC, Daedalus can show you what other shops have actually fixed it with — anonymised aggregate data across the platform. "P0420 on a 2017 F-150 3.5 EcoBoost: 47 shops have closed this code in the last 12 months; root cause was downstream O2 sensor 31% of the time, exhaust leak 24%, actual cat failure 22%, upstream O2 13%, other 10%." Real frequencies, not the model's guess.

2.5 Behavior-guideline feedback loop AI

👍 / 👎 buttons sit under every AI response. Thumbs-down opens a small dialog: too long, missing info, wrong, unclear, etc., plus a free-form note. Feedback lands in the operator review queue. When the operator approves a piece of feedback as a behaviour rule — say "always cite OEM part numbers when the question is about parts" — that rule gets injected into every Ask Daedalus call from then on. No model fine-tuning required; the system gets smarter organically based on what working shops actually want.

Rules can be scoped: global (every Daedalus user), per shop (only your shop), or per user (just this technician). Each rule has a 1–5 weight that controls how strongly it's rendered in the prompt (must / should / when practical).

2.6 NHTSA recall & TSB auto-ingest

When you add a vehicle, Daedalus fires a background fetch against NHTSA's public APIs for that exact make/model/year and pulls every active recall and technical service bulletin into the knowledge base — tagged so Ask Daedalus can cite them when you ask about that vehicle. Idempotent (re-runs don't duplicate), best-effort (NHTSA's API has intermittent outages; failures degrade quietly). The same federal data also powers the vehicle-intel chip strip (§3.6).

2.7 Vehicle Health Score

Each vehicle has a Health Score (0–100) computed from service history, manufacturer-recommended interval gaps, outstanding recalls, and historic alert signals. Shows up on the customer portal as a coloured tile ("Your truck: 82 / 100 — service for transmission fluid is overdue by 4,000 mi") and on the shop's vehicle detail as a diagnostic summary. Brake-pad / battery / fluid components are calibrated against published OEM intervals; the underlying model is documented and tunable.

2.8 AI upsell suggestions AI

On an RO, Daedalus can suggest add-on line items that fit the vehicle and the work already on the ticket — the services a thorough advisor would offer but might forget on a busy day (a cabin filter due by mileage, a fluid flush that lines up with the interval, the wiper blades the inspection already flagged).

• Suggestions are proposals, not auto-adds — the advisor accepts the ones that make sense and the line drops onto the estimate
• Grounded in the vehicle's service history and the current RO, so it doesn't pitch a service you just did
• Optional per shop (feature flag show_ai_upsell) — off for shops that don't want suggestive selling

3.1 Service wizards

Step-by-step guided procedures for common jobs — the wizard walks a tech through the sequence, the specs, and the gotchas so a less-experienced hand can do the job right and a veteran doesn't miss a step. Pairs with the RO so the work gets documented as it's done.

3.2 Live data & emissions readiness

A reference for live data parameters (SAE J1979 PIDs — what each parameter means, the normal range, and what an out-of-range value points to) and an emissions-readiness view that explains the OBD-II monitor set: which monitors must be "ready" to pass a state inspection, and the drive-cycle conditions that set each one.

3.3 Bidirectional controls

A capability catalog of bidirectional / actuator tests by system — what your scan tool can command on a given module (cycle the EVAP purge, command the cooling fan, bleed ABS, relearn a throttle body) and the safety preconditions for each. Grounded in the same ISO 14229 (UDS) service catalog the AI assistant uses.

3.4 Calibration & module replacement

Calibration covers ADAS work — the cameras and radar that drive lane-keep, adaptive cruise, and automatic braking — including which systems need a static vs. dynamic calibration after common repairs (windshield, alignment, bumper) and the conditions the bay needs to meet. Module replacement covers the program/clone/relearn steps a control module needs when it's swapped, so the new part actually works in the car.

3.5 EV battery health

An electric-vehicle high-voltage battery analysis view — state-of-health estimation and pack diagnostics for EV/hybrid work, with the high-voltage safety guidance prepended. A growing area as more EVs come through the bay.

3.6 Vehicle intel — federal-source data

Per-vehicle data pulled from federal public-domain sources, surfaced as a chip strip on the RO and vehicle detail: NHTSA recalls (and a rollup count for complaints / investigations / TSBs) and EPA fuel-economy data. A cheap one-call summary endpoint backs the chip strip; deeper lists are a click away.

3.7 Fleet telemetry & trips

For shops running a connected fleet, a telemetry dashboard ingests device data and surfaces a vehicle list with last-known state, per-vehicle telemetry and event feeds, a Trips log, and alert acknowledgement. KPI rollups summarise the fleet at a glance. Read-oriented for the shop, with the ingest side fed by fleet devices.

4.1 Dispatch board

A board of open ROs grouped by their primary technician — the most recent still-active work assignment — with an unassigned lane for jobs that need a hand. Each lane shows open ROs (anything not paid / cancelled / archived); each card carries time-on-job, customer name, vehicle label, the state badge, and the tail of the last note.

• Reassign or first-assign a job to a tech from the card
• One primary tech per RO keeps the board readable; the full work-assignment history stays on the RO
• Optional per shop (show_dispatch_board)

4.2 Scheduling queue & route optimizer

A scheduling queue (most-urgent first) for shops — and especially mobile operations — that need to plan a day of stops. The optimizer builds a proposed schedule that honours each job's SLA window, your working hours and days, customer availability, and daily caps, sequencing stops by distance.

4.3 Time & labor clock

A shift-clock chip lives in the header on every page — a tech clocks in and out for payroll without leaving what they're doing. Labor time is also tracked against each job, so the hours a tech actually spent on an RO are captured for both payroll and the efficiency report (§6.4).

• Per-shift clock in/out (payroll)
• Per-RO labor time (job costing + effective labor rate)
• Feeds the tech-time and productivity reports in §6.3

Per-line labor clock & live timer. On the RO, every labor line carries its own ▶ start / ■ stop button and a live counter that starts at zero and ticks up while a tech is clocked onto that line. Starting a line timer stops whatever else that tech had running — one active job per tech — so the recorded time lands on the right line without double-counting.

Bill estimated or actual time — your call, per line. Each labor line shows a two-way Bill: Est / Actual switch:

• Est — bill the hours you quoted (the line's quantity). This is the classic behavior and the default.
• Actual — bill the recorded clock time instead. The line re-prices to the clocked hours automatically, and the invoice totals follow.
• The switch is non-destructive: your estimated hours and the recorded time are both kept, so you can flip back and forth freely — nothing is overwritten.
• Set the shop-wide starting point under Settings → Pricing → Labor billing basis; new labor lines inherit it, and any line can still be switched on the RO.
• The per-line clock, live counter, and Est/Actual switch appear only when time tracking is on (show_time_tracking).

5.1 Maintenance reminders

Define shop-wide reminder rules ("oil service every 5,000 mi or 6 months") and Daedalus generates per-customer reminders as vehicles come due. Each reminder can be sent by email or SMS on demand, then marked sent — or dismissed / completed as the customer responds.

• Rules are shop-wide; reminders are per customer/vehicle
• Filter the queue by status or "due within N days"
• Schedule a follow-up reminder straight from an RO when you defer work
• Optional per shop (show_maintenance_reminders)

5.2 Review requests

After pickup, send the customer a one-tap link to leave a review on Google or Yelp. Configure the links once in settings; the request goes out on the channel the customer prefers. Optional per shop (show_review_requests).

5.3 Marketing campaigns & declined-service win-back

A campaign engine for win-back and follow-up. The headline use-case is declined services: when a customer turns down a recommended line, it lands in a follow-up queue, and a campaign can reach back out a set time later ("you held off on the rear brakes in March — still want to get those done?").

• Create, enable / disable, and force-run campaigns; a cron-style runner walks every enabled campaign
• Message templates substitute {customer_name}, {service}, and {shop_name}
• Declined lines are logged automatically from the approval flow
• Optional per shop (show_marketing_campaigns)

5.4 Memberships & service plans

Build and sell recurring service plans — a catalogue of membership plans, customer enrollment, and cancellation. Sell the "3 oil changes + a free inspection a year" plan and track who's enrolled. Optional per shop (show_memberships).

5.5 Coupons & promos

Promo-code administration with apply-at-estimate. Codes can be a percent off, a flat amount, or a free service, optionally scoped to a kind of line. The advisor applies the code on the estimate and the discount carries through to the invoice. Optional per shop (show_coupons).

6.1 AR aging & statements

For shops that carry receivables — fleet accounts especially — an accounts-receivable view with a bucketed aging report (0–30 / 31–60 / 61–90 / 90+ days) per customer, plus per-customer statements (opening balance, line activity, ending balance, aging) you can pull as JSON or download as CSV to send.

• Aging is computed as of any date you pick
• Statements scope to a customer and a date range
• Optional per shop (show_billing)

6.2 Vendor purchase orders

Create and track purchase orders to your suppliers. Draft a PO, add lines, then receive lines as the parts arrive — receiving bumps the on-hand count automatically. A reorder-point suggestion flags what's getting low so you can build the next PO from it.

• PO lifecycle: draft → add lines → receive (updates inventory)
• Track status, notes, shipping, tax per PO
• Reorder-point auto-suggest

6.3 KPIs & reports

A dashboard KPI strip plus a tabbed reports page. All reports are read-only and shop-scoped, and every one can be exported to CSV.

The KPI dashboard grades headline numbers (revenue, ARO, car count, effective labor rate) against benchmarks — or just ask the assistant "how's business this week?" Optional per shop (show_kpi_dashboard).

6.4 Tech efficiency & commission

An efficiency report comparing flat-rate hours billed against actual clock hours per tech — the productivity number a shop owner lives by. Flat-rate hours come from each labor line; actual hours come from the time clock (§4.3). Commission rules let you turn those hours and sales into tech pay.

6.5 Accounting export

Hand clean data to your books. Map your chart of accounts once, then export a journal for a date range in the format your accountant wants — generic CSV, a QuickBooks journal CSV, or a QuickBooks IIF file — including or excluding payments, and optionally only the unexported rows. Exported invoices get stamped so you don't double-count.

• Formats: generic CSV · QuickBooks journal CSV · QuickBooks IIF
• Filter by date range, include/exclude payments, unexported-only
• Mark-exported stamp prevents double entry
• Optional per shop (show_accounting_export) — live API sync is on the roadmap (§15.2)

7.1 Parts lookup & live pricing

Search parts and check fitment for the vehicle, with markup applied per your category defaults. With a PartsTech account connected, you get live pricing and availability from your suppliers right inside the lookup — real numbers, not a manual guess.

• Generic catalog search + manual price entry works with no setup
• Save your PartsTech key in Settings → PartsTech (username + API key); live supplier pricing/availability switches on once Daedalus's PartsTech partner setup completes
• Optional per shop (show_parts_catalog)

7.2 Van inventory

For mobile operations, track the stock that rides in the van — adjust counts as parts get used, check parts out to a job. Van inventory turns on automatically in mobile shop mode (it's the one inventory model that makes sense without a stockroom).

8.1 Loaner fleet

Manage a fleet of loaner cars: add loaners, mark one out of service, check a loaner out to an RO when a customer needs a ride, and mark it returned. Each RO shows its current loaner assignment. Optional per shop (show_loaners).

8.2 Equipment & tool checkout

Track shop equipment and tools — a tech checks a tool out and returns it, so you know who has the scan tool or the torque wrench. A calibration-due alert flags equipment that needs servicing or recertification before it drifts out of spec. Optional per shop (show_equipment).

8.3 Staff schedule & PTO

A week/day staff schedule grid plus a PTO inbox — employees request time off, a manager approves or denies, and the grid shows coverage. Optional per shop (show_employee_schedule).

8.4 Wait-area display

A public TV display for the lobby — a clean, customer-safe view of the day's queue so waiting customers can see where their car is in the line. Open it on a spare screen and leave it up. Optional per shop (show_wait_screen).

8.5 Bays

Define your bays (general, alignment, and so on) so the appointment calendar (§1.5) and dispatch board (§4.1) can place work against real capacity. Mobile shops skip bays entirely.

Third-party accounts at a glance

Daedalus runs completely on its own — you can write estimates, build repair orders, invoice, and schedule with no outside accounts at all. A few optional services plug in when you want more. Here is the whole list, whether you need it, and where to set it up. Nothing here is required to start.

9.1 Corporate rollup

Group multiple shops under a corporate group and see KPIs rolled up across every member shop — car count, revenue, and the rest, aggregated for the chain. Group-level visibility is restricted to platform administrators; individual shop users continue to see only their own shop's data. Optional per shop (show_corporate_rollup).

9.2 Public REST API keys

Mint API keys to connect outside systems to Daedalus. The secret bearer token is shown once at creation; after that you only ever see metadata, and you can revoke a key at any time. Optional per shop (show_integrations).

9.3 Outbound webhooks

Subscribe a URL to Daedalus events. Each delivery is POSTed with an X-Daedalus-Signature header — hex(HMAC-SHA256(secret, body)) — so your receiver can verify the call genuinely came from Daedalus. A test-send lets you confirm wiring before you depend on it.

9.4 Vehicle-history deep links

Configure your vehicle-history provider (Carfax or AutoCheck) and Daedalus deep-links into it for a vehicle. This is a deep link driven by your configured provider + partner ID today — not a licensed in-app data feed.

9.5 Notifications

An in-app notification system with a server-side outbox backs the alerts you see (and the outbound email/SMS the rest of the product sends). The outbox is the single, auditable path messages flow through, which is also how comms consent and opt-out (§12.3) get enforced uniformly.

10.1 Storage architecture

• Postgres (Fly Managed): customer, vehicle, RO, estimate, invoice, payment, communications, audit log — all the relational shop data, shop-isolated by row-level shop_id filtering enforced at the repo layer
• SQLite (persistent volume): per-instance knowledge base, calibration captures, JWT revocation list, auth user table. Survives every deploy via a Fly mounted volume.

10.2 Multi-tenant isolation

Every write carries a shop_id. Every read filters by it. Audit-tested across customer, vehicle, RO, estimate, invoice, payment, appointment, technician, time-clock, parts, and notes tables. Two shops sharing the platform can't see each other's data even by URL-guessing.

10.3 BYO-bucket backup

Connect your own S3-compatible bucket (AWS S3, Backblaze B2, Cloudflare R2, Wasabi, MinIO). Daedalus encrypts the backup client-side before upload using a key you generate and hold — we never see your data in plaintext on the way out. Restore tested end-to-end; documented as the "mirror to live" recovery path.

10.4 Three ownership tiers

11.1 Authentication & 2FA

• JWT in HttpOnly cookies, not localStorage — immune to XSS token theft
• bcrypt password hashing, cost 12; per-row hash-version column for future algorithm rotation
• Per-IP + per-username rate limits on login, signup, and forgot-password
• Refresh-token rotation with per-user revocation list (logout clears all your tokens server-side, not just the client)
• Beta-invite tokens are single-use, time-boxed, raw token never stored (only a hash)

Two-factor authentication (TOTP). Turn on 2FA from Settings → Sign-in & security: scan the QR into any authenticator app, verify a code, and save the backup codes. Strongly recommended for owners and managers. The TOTP math is hand-rolled (no third-party dependency); the secret and backup codes can be cleared with a verified disable.

11.2 Browser hardening

• Content-Security-Policy header — no inline scripts in production except where explicitly nonce'd
• Strict CORS (allow-list of two domains: daedalusautomotive.com + .app)
• Secure / SameSite cookies; HTTPS-only enforced via Fly edge

11.3 Audit log

Every meaningful state change writes an audit-log row: who, when, what changed, from what value to what value. Shop-scoped (you only see your own); viewable from Settings → Audit. Tamper-resistant by design — append-only — there's no UPDATE / DELETE path through the API.

11.4 Privacy posture

• No third-party analytics, no marketing trackers, no Google. The marketing page makes one HTTP call: fetching its own CSS.
• Crash reporting via Sentry is opt-in only; when enabled, PII is stripped before send
• Your customer data is never used to train shared models

The full data-rights machinery — subject-access exports, erasure, consent, communications law, retention, and your shop's own regulatory obligations — has its own chapter (Chapter 12).

12.1 Data-subject requests (export & erasure)

Two request kinds back the privacy rights a customer can exercise:

• Export — serialize every customer-tied row (the customer, their vehicles, ROs, invoices, and communications) into a single JSON dataset for a subject-access / portability request.
• Erasure — a GDPR Article 17 deletion with the tax-retention exception. Personal data is removed/archived while the financial records the law requires you to keep are retained under a legal hold (§12.4). Erasure can't quietly destroy the invoices you're obligated to keep for tax.

A background scanner watches for aging requests so a statutory deadline (GDPR ~1 month / CCPA 45 days) doesn't slip by unnoticed. Optional per shop (show_privacy_dsr); managed from Settings → Privacy & data.

12.2 Consent lifecycle

Terms / Privacy consent is captured at signup and stamped with the exact version the user agreed to, from a single source of truth (currently v1.1, effective 2026-06-15) — never a hardcoded guess. When the published version changes, the drift is detected against that constant and users are prompted to re-consent. Withdrawal is recorded with an audit trail.

12.3 Communications law (TCPA / CAN-SPAM)

Every outbound message respects the communications-law rules so a marketing campaign can't become a liability:

• Consent capture before marketing contact, recorded per customer
• Opt-out / unsubscribe honoured on every channel; an opted-out customer is suppressed
• Quiet hours so texts don't go out at 2 a.m.
• Transactional vs. marketing split — an approval link or "your car's ready" is transactional and always goes through; promotional sends are gated on consent

12.4 Data retention & legal holds

When a shop churns, its operational data is eligible for cleanup after a grace period — but financial records the law requires (invoices, payments) are protected by a legal-hold carve-out so they survive a 7-year tax-retention window regardless of the operational grace. Reconciling "erase the customer" (§12.1) with "keep the tax records" is the same legal-hold mechanism in both directions.

12.5 Shop compliance profile

The shop-facing side: a per-shop compliance profile keyed on your state, tracking the obligations that actually apply to you and the deadlines that generate fines if you miss them.

• State profile + applicable obligations — configurable per shop, since the rules vary by state
• License & permit renewals with expiry reminders
• Technician certifications (ASE, EPA 609) and their expiry
• Equipment inspections due dates
• Hazardous-waste / used-oil disposal log for your EPA / state records

Deadline reminders are emitted by a background worker so a license renewal or a cert expiry doesn't sneak up on you. Managed from the Compliance page; writes require the shop-settings permission.

13.1 Backup & recovery

Two layers: Fly's managed Postgres snapshots (5-day retention, daily) cover the cloud-hosted relational data; your own BYO-bucket schedule (if enabled) handles encrypted exports of everything — Postgres dump + per-instance SQLite + uploaded photos. A tools/mirror-to-live recovery script ingests a bucket back into a fresh Daedalus instance for full disaster recovery.

13.2 Monitoring

• /healthz + /health endpoints (no auth) for uptime checks
• Fly platform health checks every 30s
• Anthropic API balance / quota visible in the Settings panel for master_dev

13.3 Persistence guarantees

• Customer / vehicle / RO data → Postgres → never wiped by a redeploy
• Auth tokens / KB / per-shop assets → SQLite on Fly volume → never wiped by a redeploy
• Logs / metrics → Fly's log retention (90 days)

14.1 Founding rate

The first shops to join lock in the founding rate: $49.99/mo, for life — full access, and the price never changes as long as your account stays active, even as your shop grows. When the founding window closes, new shops join at the standard tiers below.

14.2 Standard tiers

Solo $99.99/mo (1 seat) · Shop $149.99/mo (5 seats) · Shop Plus $249.99/mo (unlimited seats). Cancel anytime; your data stays exportable. Customers — the drivers your shop serves — are always free. Daedalus does not charge per-RO or per-vehicle: a shop is a shop. Current numbers always live on the pricing page.

14.3 Subscription & billing

The billing plumbing for your shop's own subscription is built on Stripe: start a checkout for a plan, open the Stripe customer portal to manage your card and invoices, and see your current plan, status, and seat count in Settings → Subscription. Stripe's webhooks keep your subscription state in sync server-to-server (signed and idempotent).

15.1 Online card processing Coming soon

In-shop card charges through a Stripe Terminal reader, and the SaaS subscription billing, are already built (§1.4, §14.3). What's still landing: full customer-portal "pay online" card processing turned on by default (it's wired but gated behind a Stripe secret today), a Square option, and broader payment-service-provider choice.

15.2 Accounting API sync Coming soon

One-way live export of invoices + payments into QuickBooks or Xero over their APIs. File export (CSV / QuickBooks journal / IIF) is available today (§6.5); the live API sync is the upgrade.

15.3 Native mobile app Coming soon

Today the platform is responsive web — tablets and phones work fine, and it installs as a PWA — but a native app for techs in the bay (with offline RO write, photo capture, voice-to-text on inspection items) is on the list.

15.4 Live scan-tool link Coming soon

Daedalus has a separate scanner-side product (Daedalus Diagnostic) that reads the CAN bus directly from the OBD-II port. The shop product already carries the diagnostic reference suite (Chapter 3) and accepts scan-tool export attachments on an RO; the next big integration is pulling DTCs live from the scanner into the RO with one click.