Kuschick Adapter Effort Estimate

Status: Rough estimate after grill session Purpose: Size the Busflow-owned Kuschick adapter as a partner-facing Satzart/xtoura MVP plus later Busflow product capabilities.

Assumptions

• Kuschick remains System of Record for the Satzart/xtoura MVP.
• Satzart receives a wrapper for the Kuschick booking form flow, including real confirm writes to Kuschick.
• The first adapter is lossless and system-specific; full Busflow domain normalization happens in a later central Busflow layer.
• Read-heavy starting data is cached and preloaded twice daily, e.g. 02:00 and 14:00.
• Form initialization uses cache and background refresh; final write operations call Kuschick synchronously.
• Satzart MVP uses No-PII Persistence where possible.
• No admin/debug UI in MVP; Swagger/OpenAPI, structured logs and stored raw read responses are sufficient.
• Transport remains a risk: the provided PDF describes XML-over-HTTP, not SOAP/WSDL.

T-Shirt Sizes

Size	Meaning
XS	< 1 day
S	1-2 days
M	3-5 days
L	6-10 days
XL	11-20 days

Satzart / xtoura MVP

Module	Size	Effort	Notes
Protocol verification & Kuschick sandbox spike	S	1-2d	Confirm XML-over-HTTP vs SOAP/WSDL, auth key generation, timeout behavior.
Partner/Operator integration config	XS-S	0.5-1d	Operator-scoped Kuschick credentials, base URL, provider settings.
Partner API auth	S	1-2d	API key per partner-operator integration, hashed storage, rotation model, optional IP allowlist check.
Kuschick transport client	S-M	2-4d	Request builder, MD5 daily key, XML parse/build, provider error handling.
OpenAPI / Swagger contracts	S	1-2d	Public DTOs, cache semantics, error models, polling status. Nest/Swagger already exists.
Scheduled preload jobs	M	2-4d	Twice-daily preload of products/reise starting data, availability-adjacent data, payment/CRM/options where feasible.
Cache model & refresh jobs	M	2-4d	Cache entries, age metadata, refreshJobId, polling states, pragmatic stale-while-revalidate basics.
Composite form initialization DTO	M	2-5d	UX-ready model: fields, labels, requiredness, payments, CRM, seat options, validation plan, provider IDs.
Quote / validate flow	M	2-4d	Kuschick BUCHUNG with buchungsart=Anfrage, quoteId TTL, payload binding.
Confirm flow	M	2-4d	Kuschick BUCHUNG with buchungsart=Buchung, provider outcome states, idempotency/correlation.
Idempotency & fremdvorgang handling	S-M	1-3d	Correlation ID, test whether Kuschick stores/searches fremdvorgang, duplicate-submit protection.
Raw response storage & PII redaction	S	1-2d	Store read/cache raw responses; avoid durable PII for booking data in Satzart mode.
Error taxonomy & partner-safe messages	S-M	1-3d	provider rejected, provider unavailable, provider outcome unknown, support codes.
Tests & mocked provider fixtures	S-M	2-5d	XML fixtures, cache states, timeout/outcome-unknown cases, quote/confirm contract tests.
Deployment/ops hardening	S	1-2d	Env config, secrets, logs, basic monitoring, rate limits.

Pragmatic solid MVP total: roughly 17-32 person-days. This assumes an experienced implementation in the existing NestJS API, scoped tightly around one provider and one partner-facing booking flow.

Very thin functional spike: roughly 7-12 person-days. This proves the Kuschick transport, form starting data, quote/confirm path and OpenAPI shape, but deliberately avoids full resilience, complete edge-case tests, deep cache polish and advanced privacy modes.

Productized Busflow adapter: roughly 30-50 person-days. This is the right frame if the adapter is treated as a durable Busflow product surface with support workflows, stronger observability, broader provider abstractions and better operational tooling.

MVP Cut

The MVP should include:

• Operator-scoped Kuschick credentials.
• Partner API key auth and optional IP allowlist.
• Kuschick transport adapter for the booking-form Satz-Typen.
• Twice-daily scheduled preload.
• Cache-backed composite form initialization.
• Polling-based background refresh.
• quote / validate with short-lived quoteId.
• confirm write to Kuschick for Satzart.
• Clear provider error semantics.
• Correlation via Busflow ID and, if usable, Kuschick fremdvorgang.
• No-PII persistence mode for Satzart.
• Swagger/OpenAPI.

The MVP should exclude:

• Full Busflow domain import into TourTemplate, TourDeparture, BoardingPoint, or Commerce tables.
• Two-way sync.
• Buchungs-/Abrechnungs-Sync as a Satzart feature.
• Admin/debug UI.
• SSE/WebSocket updates.
• On-the-fly Busflow price calculation.
• OAuth/JWT partner ecosystem.

Phase 2 / Busflow Product Capabilities

Module	Size	Effort	Why Later
Central Busflow normalization layer	L-XL	10-20d	Maps system-specific adapter DTOs into Busflow import/staging models.
Migration/staging pipeline	XL	15-30d	Review UI, conflict handling, materialization into Backoffice/Commerce.
Product/stammdaten import expansion	L	6-12d	Deeper PRODUKTE, PRODUKTDATEN, STAMMZUSTIEGE, STAMMVERSICHERUNGEN use.
Buchungs-/Abrechnungs-Sync	XL	15-30d	Strategic Busflow USP, not a Satzart wrapper feature.
Offline queued Busflow booking	XL	15-30d	Accept requests when Kuschick is down; needs customer-facing status and manual process.
Integrator cockpit	L	8-15d	Cache status, raw responses, provider health, manual resolution workflows.
SSE/WebSocket refresh updates	M	3-6d	Better UX after polling MVP proves useful.
OAuth/JWT partner auth	M-L	5-10d	Needed for larger partner ecosystem and scoped delegation.
On-the-fly calculation layer	XL	20d+	Requires importing/calculating Kuschick pricing basis; high domain risk.
Advanced privacy/retention controls	M-L	5-10d	Per-mode retention, encryption, audit access, deletion workflows.

Risk Multipliers

Risk	Impact
No reliable Kuschick test system	Adds 20-40% due to manual verification and delayed bug discovery.
fremdvorgang not stored/searchable	Adds complexity for duplicate-submit and outcome-unknown handling.
Slow or unstable provider responses	Increases caching, retry and timeout design work.
Hidden Kuschick validation rules	Expands quote/confirm mapping and partner error handling.
Browser-direct integration required	Raises security scope; API keys in clients are unacceptable without a different auth pattern.
PII retention requirements change	Can add encryption, retention and access-control work.

Recommendation

Build the MVP as a solid wrapper product, not as a throwaway integration:

1. Start with protocol verification and fixtures.
2. Build API key auth, operator credentials and transport client.
3. Implement cache/preload before polishing the form DTO.
4. Ship composite form initialization plus polling refresh.
5. Add quote/confirm with correlation and explicit outcome states.
6. Keep Busflow migration/sync as Phase 2, where it becomes product leverage instead of partner custom work.

Commercial Packaging Recommendation

For Satzart, package the work as a small fixed first phase rather than selling the full productized adapter.

Recommended billable frame: "Kuschick Booking API Foundation" at roughly 2.5 weeks. This corresponds to the very thin functional spike plus selected MVP hardening. It is commercially attractive for a price-sensitive customer and still funds Busflow's research base.

The offer should avoid promising the full pragmatic MVP if only the spike is billed. Instead, phrase the deliverable as:

• working Kuschick booking-flow foundation for the agreed first operator/use case;
• documented API via Swagger/OpenAPI;
• basic cache/preload behavior for form starting data;
• quote/confirm flow against Kuschick;
• structured provider errors and correlation IDs;
• no admin/debug UI;
• no Busflow migration/staging;
• no two-way sync or Buchungs-/Abrechnungs-Sync;
• no guarantee that all Kuschick edge cases are covered in phase 1.

Internally, Busflow can build the implementation slightly more solidly than the paid scope requires. That creates strategic reuse without increasing Satzart's contractual expectations. Further hardening, extra Kuschick Satz-Typen, advanced offline behavior, provider-sync features or support tooling should become explicit follow-up phases.