Dinner turned into a hiring and architecture memo before bed.
Two startup friends were building a product around data and decision-making. We met downtown, and afterward I sent them the practical list I had been talking through over dinner.
For engineering recruiting, build a pipeline. Use the available recruiting services, vet technical ability, and have experienced technologists help interview the first engineers. The early hires needed to understand the business as well as the code. I did not want them lowering the technical bar just to fill seats.
For product, learn from users and bring in research once there was something real to show. A modern front-end framework was fine. The user journey should stay separate from the decision engine and the underlying data.
For the backend, I suggested APIs in front of the data model and clear contracts for how the product asked for information. Swagger was useful for writing those contracts down.
Then came the warning. Their data would not be enormous at the beginning. Reaching immediately for Kafka, Elasticsearch, Spark, stream processing, and the rest could make it easier to lose context before the business needed that machinery.
I called it medium data with a lot of algorithms, heuristics, and intelligence. The sophisticated part was understanding the business and the meaning of the data, not collecting the largest possible technology stack.
The note ended with a slightly mean joke about making friends with the local machine-learning startup so they could hire a couple of its engineers if it failed. I said I was only twenty-five percent kidding.
It was not a formal consulting engagement like the network I had been sketching. It was dinner, a follow-up email, and the best list I could give them that night.