Situationen
Ett leadgenereringsföretag som sålde i USA, med en produkt som måste göra tre saker samtidigt: fånga in och kvalificera leads, avgöra vad varje lead var värt och routa samtal mellan köpare och säljare i realtid. När jag kom in fanns inget utvecklingsteam. Det var jag.
Leadkvaliteten poängsattes av ett tredjeparts-API som debiterade per anrop. Det fungerade, i den meningen att det returnerade ett tal. Det gick inte att justera, dess latens var någon annans problem, dess pris var någon annans beslut och dess gränsfall kring amerikansk telemarketinglagstiftning var någon annans tolkning.
Scoringmodellen
Jag ersatte det med en egen modell: utformad, annoterad, tränad, serverad och utvärderad internt, tillsammans med den feature-pipeline som matade den.
Indata var den intressanta delen - device intelligence, uppslag av linjetyp och operatör, ryktesdata, beteendehändelser under själva ifyllandet av formuläret och samtyckesmetadata. Om ett nummer är en mobil hos en stor operatör, och om personen fyllde i formuläret på elva sekunder eller nittio, säger mer om ett leads värde än nästan allt folk skriver i demografiska fält.
Att ta hem det gav fyra saker leverantören inte kunde sälja: kontroll över latensen, en kostnad per lead som sjönk med volymen i stället för att stiga, vår egen läsning av gränsfallen kring compliance och - viktigast av allt - möjligheten att avgöra hur konfidensen skulle styra routing och pris. Ett score du inte kan ifrågasätta är ett score du inte vågar agera på.
Resten av produkten
En Django-backend som exponerade både REST och GraphQL, på PostgreSQL för transaktionsdatan och ClickHouse för analysen med stora volymer och scoringtelemetrin - två databaser eftersom en och samma sorts fråga inte tjänar båda, och att låtsas något annat är hur analysen till slut bromsar precis det som drar in pengarna.
Adminbackofficen hade JWT-API:er som introspekterar Djangos egna adminmetadata, så att en ny modell automatiskt exponerades för mobilklienterna. Det sparade en vecka varje gång och, mer värdefullt, tog bort en klass av buggar där mobilappen och webbadminen var oense om hur en post såg ut.
Samtalsinfrastruktur från början till slut: flera dialer- och operatörsplattformar för outbound och inbound, routingtjänster, ett distributionslager mellan köpare och säljare, och en egen backend som orkestrerade liveflödet från uppringning till transfer, inspelning och disposition. Röstagenter på outbound. Kontinuerlig kontroll mot do-not-call- och telemarketing-samtyckesregler, inbyggd i själva accepterandet av leadet och inte påklistrad efteråt, för en compliance-kontroll som körs efter att du redan har ringt är en dokumentation av överträdelsen, inte en kontroll.
Sedan delarna ingen räknar: ett eget CMS, tre Flutter-applikationer för iOS och Android som täckte B2B, B2C och admin, och produktionsinfrastrukturen - härdad Ubuntu, Nginx, Docker, releaser utan driftstopp, DNS hos två leverantörer, certifikat, brandvägg och blockering av intrång.
Hur det var att vara ensam på hela produkten
Mest klargörande. Det finns ingen att förhandla ett gränssnitt med och ingenstans för ett missförstånd att gömma sig. Men det sätter ett hårt tak på hur mycket som kan pågå samtidigt, och det gör dokumentation till en självförsvarshandling snarare än en artighet - personen som inte kommer att minnas varför den här kön har två sekunders fördröjning är jag, i mars.
Vad jag skulle göra annorlunda
Jag skulle ha byggt modellens utvärdering och övervakning samma dag som modellen, inte efter att den gått i produktion. Den presterade bra, och det visste jag från offline-utvärderingen - men under de första veckorna hade jag inte snabbt kunnat bevisa att den fortfarande presterade lika bra i produktion. Den luckan är obekväm, och den gick att undvika.