Before Zachary Markin was running a software company, he was trying to make a food business work. The Fresh Corner Cafe, which he co-founded in Detroit, needed invoicing, records, and a way to understand its operations. He built the tools himself. A founder with a chemical engineering education had found a reason to learn software: there was work to do, and the available arrangements needed improving.
There is something wonderfully unceremonious about that entrance into technology. No grand announcement was required. An invoice had to go somewhere. Information had to survive the journey. A business needed to keep track of itself. Markin’s subsequent career has become larger and more specialized, but those early tools offer a useful way into it. He has repeatedly returned to the space between an organization’s ambitions and the machinery that allows people to carry them out.
A farm, then a lighting desk
Markin grew up in south-central Wisconsin, the youngest of three brothers, on a family farm with sheep, crops, and a large garden. He remembers trying to keep up with his older brothers. At school, he worked as an auditorium lighting technician, a job that led him to Electronic Theatre Controls in nearby Middleton.
There, founder Fred Foster spent time with him and encouraged his interest in entrepreneurship. Markin credits Foster with changing his view of business: a company could contribute to the lives of its employees, customers, and neighbors. Long before he became a CEO, he had met one who made the role seem worth pursuing.
Seven shops and a classroom idea
At the University of Michigan, Markin studied chemical engineering and took a Social Venture Creation class. One assignment became Get Fresh Detroit, the venture he built with Noam Kimelman. By 2011, the business was supplying seven neighborhood corner stores with vegetable packs. Each pack included produce and a recipe, intended to make a meal for as many as four people.
The idea had received $2,500 in grant awards. That is a satisfyingly concrete beginning: a class, a modest sum, seven shops, and something a customer could take home. The recipe was part of the product. A bag of ingredients asks the buyer to solve another problem; a recipe makes the next step easier. The detail fits a career increasingly occupied with how one step connects to the next.
Get Fresh Detroit was listed among the student semifinalists in the 2010 Accelerate Michigan Innovation Competition, with both Kimelman and Markin named. The business had moved beyond a classroom exercise quickly enough to be considered alongside other student ventures. Its later chapter, Fresh Corner Cafe, operated for eight years. For Markin, running it also became a practical education in software.
The useful things underneath
The next part of the story takes place in the plumbing. Markin worked as an independent software consultant and data infrastructure engineer, building integrations, warehouses, pipelines, and analytics tools. These are the parts of a system that rarely get a launch party. They determine whether the information needed for a decision is available, intelligible, and in the right place.
By April 2017, he was managing the Civic Analytics Network at Harvard Kennedy School’s Ash Center. His writing there examined how New Orleans encouraged city departments to propose useful analytics projects. The city’s approach included examples, guidance, office hours, and a checklist for assessing possible work. The people with data skills needed the experience of the departments doing the jobs.
It was a fitting subject for someone who had discovered data infrastructure through operating a business. Technical ability alone does not select the right problem. People close to the work supply knowledge that a central team may lack. Markin’s path from food distribution to civic analytics put him in two settings where a system’s usefulness depends on understanding what happens outside the system.
A person is more than a database field
In March 2016, Markin wrote about a consulting project connecting a job platform to an applicant tracking system. On the surface, it was ordinary integration work: a person applies in one place, and their information appears in another. Underneath, the two products had different ideas about what a person’s record could contain.
His examples made the consequences visible. A degree recognized by one system could be reduced to an unspecified category in the other. A gender recorded accurately in the first could fail to fit the second system’s choices. Translating the record required decisions that the word “integration” conveniently conceals.
The essay is a revealing piece of his public writing because it follows a technical detail into a human consequence without abandoning the technical detail. A field definition can decide what survives a transfer. A tidy database can still describe someone poorly. Software builders choose the categories; users live with the results. In Markin’s account, careful engineering includes noticing the assumptions hidden inside those categories.
“Seeing the growth of individuals over the years.”
Zachary Markin, on a favorite part of building HTD
A company measured in other people’s progress
Today Markin is co-founder and CEO of HTD Health, where his responsibilities include company direction, business development, and technology consulting. The firm has its headquarters in New York and offices in Nashville, Portland, Warsaw, and Łódź. Its current company figures list more than 200 employees and more than 250 products delivered. The work involves teams spread across countries as well as disciplines.
In October 2023, Markin described HTD as having reached eight-digit revenue over seven years without external funding. He also identified passing 100 team members and establishing a production operations team as milestones. Those were dated observations about the company at that point, rather than a promise about every subsequent year.
Asked about a favorite memory, he chose the growth of colleagues. He could look at someone’s progress across five years and imagine that person eventually running the company. It is a pleasant complication to the usual founder narrative. The organization becomes interesting partly because other people acquire the ability to lead it. A CEO can enjoy becoming less indispensable, which is an underrated ambition.
The paperwork becomes a product
Alongside HTD, Markin built Exos, a governance, risk, and compliance software company. Its subject matter sounds like the contents of a filing cabinet after a particularly diligent afternoon. The actual task is organizational: establish what people are supposed to do, help them do it, and retain evidence that the work happened.
MedStack publicly announced its acquisition of the Exos assets and brand on October 3, 2023. The amount was undisclosed. The product joined a platform with which its policy templates, documented workflows, and employee training could be combined. It is another instance of a familiar Markin concern: making the supporting work of an organization easier to perform consistently.

The product’s task builder assigns work and turns procedures into actionable playbooks. Its evidence tools retain a history; its asset tracker accounts for hardware and software access. These functions make an interesting companion to the code he once wrote for a food business. Both concern the unglamorous information that allows an operation to keep its promises.
Show the machine what you mean
In April 2026, Markin’s attention turned publicly to an experiment with AI coding agents. The HTD Labs team asked an agent to generate a React component with different supporting material. Some runs received written implementation guidance. Others received that guidance plus executable code examples. The distinction sounds small until the output arrives.
On the team’s scorecard, guidance alone produced scores of three to four out of ten. Guidance accompanied by examples scored eight to nine. Markin presented this as a result from one experiment, with a specific task and assessment method. It provides a reason to test how documentation works in practice, rather than assuming that a tool will apply every rule it receives.
Same task. Different supporting material.
Reported ranges for this React component experiment. These results describe the team’s assessment, not a general benchmark.
The practical implication concerns the material a team prepares before asking for code. Written standards still have a purpose. Working examples provide another form of instruction, carrying a pattern directly into the task. For a founder whose first software served an existing operation, there is a certain continuity in this insistence on checking the output against the job.
The missing half of the plan
A follow-up published in May 2026 looked at planning. The team supplied an agent with four project documents and asked for a full-stack implementation plan. It returned 2,245 lines of backend code snippets and no frontend implementation. A response can be impressively lengthy while leaving a substantial part of the assignment untouched. Anyone who has attended a meeting will recognize the possibility.
Markin described how context about the frontend changed the result, including an improvement to the backend plan despite no new backend documentation. His argument was that different stages of work need different kinds of context. Planning requires enough breadth to see the whole project. Implementation needs relevant detail for the particular task.
That distinction brings the story back to the operational questions running through his career. What information does this person, team, or tool need? What disappears in translation? How do you know whether a process has worked? The technologies change, but the questions remain stubbornly useful.
Markin also appears on the team at Ninety5Health, an investment and consulting group that backs early-stage companies. The role places him alongside other founders and operators, working with ventures still forming their habits. His own route offers several possible beginnings: a classroom assignment, a food-distribution business, a consulting project, a company built with colleagues. The through line is the work required to turn an idea into something people can use tomorrow morning.