Custom Development
Wenn Billbee für dich mehr meint als ein zusätzliches Feld
Viele Teams kombinieren Billbee mit Lager- und Versandprozessen und stoßen an Stellen, wo ein Billbee WMS oder eine tiefere Billbee-Erweiterung im Sinne von Regeln, Oberflächen und Automation sinnvoll wäre. Genau dort setzt beeUnity an: als modulare Plattform mit klarer Produktlinie – und mit Custom Development nur dort, wo es technisch und strategisch passt.
Statt offener Sonderprojekte ohne Rahmen arbeiten wir mit zwei festen Modellen. Das reduziert Reibung bei Angebot und Umsetzung und hält neue Funktionen wartbar für alle Nutzer:innen.
Immer der erste Schritt: Scoping & Konzeptionsphase
Bevor wir Zeit in Umsetzung stecken, klären wir fachlich und technisch den Rahmen. Diese Phase ist kostenpflichtig und liefert unter anderem MVP-Idee, Risiken, Abhängigkeiten und eine Empfehlung für Feature Flex oder Feature Scope.
Inhalt in Kurzform
- Anforderungen strukturieren und für beeUnity bewerten
- Funktionsumfang abgrenzen, technisch einordnen
- Modellwahl vorbereiten
Ziel: belastbare Entscheidungsgrundlage statt grober Schätzungen.
Zwei Modelle
Gleiche Qualität, unterschiedliche Planbarkeit: dynamischer Aufwand mit Budgetdeckel versus Festpreis für klar umrissenen Umfang.
beeUnity Feature Flex
Umsetzung nach Aufwand innerhalb vereinbarter Budgetgrenzen pro Phase.
Für komplexe oder noch nicht vollständig greifbare Themen: iterativ entwickeln, transparent abrechnen, vor jeder Erweiterung freigeben.
Typisch passend wenn
- neue Module oder Integrationen mit offenen Randbedingungen
- Regelwerke, dynamische Logik, mehrstufige Releases
Ablauf und Details anzeigen
- Scoping (kostenpflichtig)
- Erster realistischer Umsetzungsrahmen
- Umsetzung nach Aufwand mit Budgetdeckel je Abschnitt
- Abstimmung vor nchster Phase
Vorteil: Flexibilitt und Transparenz ohne starren Festpreis, solange der Aufwand noch schwer seris fixierbar ist.
beeUnity Feature Scope
Festpreis für einen klar definierten MVP oder ein Funktionspaket.
Wenn Scoping eindeutige Grenzen liefert: verbindlicher Umfang, Festpreis, Umsetzung innerhalb dieses Scopes; Änderungen außerhalb separat.
Typisch passend wenn
- Workflow oder UI-Erweiterung eng beschreibbar
- stabiler Funktionswunsch mit hoher Kostensicherheit
Ablauf und Details anzeigen
- Scoping (kostenpflichtig)
- Definition MVP / Paket
- Festpreisangebot für genau diesen Umfang
- Umsetzung im vereinbarten Scope
Vorteil: klare Erwartung an Leistung und Kosten.
Kurzvergleich
Ein Blick auf die wesentlichen Unterschiede, ohne die ausführlichen Beschreibungen oben zu wiederholen.
| Kriterium |
Feature Flex |
Feature Scope |
| Kostensicherheit |
Budget je Phase / Block, Freigaben vor Mehraufwand |
Festpreis für den beschriebenen Umfang |
| Ideal, wenn … |
Dynamik, noch offenen technischen Details |
Klar abgrenzbarem MVP oder Paket |
| Änderungen während der Umsetzung |
Über Freigaben und Phasen steuerbar |
außerhalb des Scopes separat bewertet |
Gemeinsamer Rahmen für beide Modelle
Custom Development soll produktfähige Erweiterungen liefern – nicht wartungsintensive Einzelprojekte. Deshalb gelten unabhängig vom Modell dieselben Leitplanken.
- Passend zur beeUnity-Produktstrategie; keine dauerhaft exklusive Einzel-Lösung nur für ein Unternehmen.
- Neue Funktionen werden in beeUnity integriert; Rechte an Architektur und Code verbleiben bei beeUnity.
- Keine gesonderte Sonderwartung für eine isolierte Insellösung; laufende Pflege erfolgt über das Produkt.
- Leistungen außerhalb des Vereinbarten sowie externe API-/Lizenzkosten werden separat betrachtet.
Du finanzierst keine parallele Software neben beeUnity, sondern eine sinnvolle Erweiterung der gemeinsamen Plattform.
Beispiele (ohne Anspruch auf Vollständigkeit)
eher Feature Flex
- komplexe Versand- oder Packlogik
- Regelwerke mit vielen Variablen
- Integrationen mit unsicherer Datenlage
eher Feature Scope
- definierter Lager-Workflow
- klar beschriebene UI-Erweiterung
- zusätzlicher Export, Filter oder Freigabeschritt
Häufige Fragen
beeUnity arbeitet eng mit deinen Billbee-Daten (Bestellungen, Artikel, Versand). Custom Development adressiert typische Wunschthemen wie Lagerprozesse, Packlogik, Regeln und UI – als Erweiterung der Plattform, nicht als separates Mini-Produkt neben beeUnity.
Custom Development bei beeUnity ist grundsätzlich produktorientiert. Neue Features setzen wir nur um, wenn sie sinnvoll in beeUnity integrierbar sind und nicht als isolierte Sonderlösung dauerhaft separat gepflegt werden müssen.
Weil größere Anforderungen bereits vor der Umsetzung erheblichen fachlichen und technischen Analyseaufwand verursachen. Die Scoping-Phase schafft Klarheit, reduziert Projektrisiken und liefert die belastbare Grundlage für die weitere Umsetzung.
Immer dann, wenn Umfang, Risiken oder technische Details noch nicht vollständig abschätzbar sind. Feature Flex bringt in solchen Fällen mehr Transparenz und vermeidet unrealistische Festpreise.
Wenn der gewünschte Funktionsumfang nach der Scoping-Phase klar beschrieben und verbindlich abgegrenzt werden kann.
Die entwickelten Funktionen werden als Bestandteil von beeUnity integriert und im Rahmen der regulären Produktpflege weiterentwickelt. Eine individuelle Sonderwartung für exklusive Einzellösungen ist nicht Bestandteil des Modells.
Zusätzliche Anforderungen außerhalb des vereinbarten Rahmens werden separat bewertet und je nach Modell neu eingeordnet oder als Folgephase geplant.
Nächster Schritt
Wir prüfen mit dir, ob dein Thema als Billbee-nahe WMS- oder Plattform-Erweiterung sinnvoll in beeUnity passt – und welches Modell dazu passt.
