Justin Fulcher has worked at the intersection of technology and regulated institutions for close to two decades. During that time, he built tech platforms for government agencies, hospital systems, and federal health programs with strict compliance requirements, multi-layered procurement processes, and decision-making structures that don’t resemble anything in the private sector.
His view is that the most common mistake technology founders make when targeting public sector clients isn’t a product mistake. It’s a research mistake. Founders who skip the work of understanding how an institution actually functions tend to build products that institutions resist adopting, regardless of how useful the technology is.
How New Technology Enters an Organization
Justin Fulcher built RingMD into a government-focused telehealth services platform serving federal agencies, including the Indian Health Service, across 37 states. Building that business required navigating procurement requirements, FedRAMP compliance architecture, clinical workflow integration, and stakeholder structures across multiple jurisdictions. What he observed consistently was that the technology wasn’t the hard part. Getting an institution to adopt new technology was.
The difficulty wasn’t resistance for its own sake. It was structural. Institutions have budget cycles, approval chains, compliance obligations, and internal processes that determine how and when new technology can enter the organization. A product that doesn’t account for those structures creates friction at every stage of the sales and implementation process, not because the institution is being difficult, but because the product wasn’t designed for how the institution works.
Founders who build before studying the client tend to discover these constraints late, after significant development investment, when changing the product is expensive and the sales cycle is already stalled.
What Founders Should Study About Regulated Environments
For Fulcher, studying a public sector client isn’t conventional market research. It’s about understanding the internal logic of the institution you’re trying to sell to.
That means understanding who actually holds authority to approve new technology, which is frequently not the person founders meet first. It means understanding how the institution’s budget works, when its procurement cycles open, how a new product will connect to its core systems, and what the compliance and security requirements are for any new vendor. In government healthcare contexts, those requirements can include FedRAMP authorization, HIPAA compliance, and FISMA certification — all of which have to be designed in from the beginning, not retrofitted after the product is built.
It also means understanding what the institution is already trying to accomplish. Public sector and regulated healthcare institutions are typically running against existing mandates and internal initiatives. A product that asks the institution to adopt a new agenda will encounter more resistance than one that fits into something the institution was already working to do. Finding that alignment requires understanding the institution’s goals before the build begins.
Why Founders Skip Research in High-Stakes Environments
Founders building companies in consumer markets are rewarded for moving fast, shipping early, and iterating. That rhythm works well in consumer markets, where adoption decisions are made by individuals. It works less well when the customer is a government agency or a hospital system with a 12-month procurement cycle and a compliance review process that predates the product by years.
Founders frequently assume a strong product will overcome institutional friction. In high-stakes environments where institutions are accountable for what technology they deploy, that assumption tends not to hold. The product still has to clear internal processes that take time whether the product is good or not.
Founders who move fast into institutional markets often encounter their first real sales cycle and interpret the slowness as a negotiation or relationship problem. In Fulcher’s view, it’s more often a design problem. The product wasn’t built for how the institution buys and deploys technology.
Where Products Stall Inside Government Institutions
Products that weren’t designed around institutional constraints tend to stall at predictable points. They fail compliance reviews because security architecture decisions were made without reference to the client’s requirements. They require workflow changes that no one inside the institution has authority to authorize. They lack an internal champion because no one inside the organization was consulted during the build phase.
Procurement processes in government contexts are designed to be deliberate. Institutions serving vulnerable populations, managing public funds, or handling sensitive data have structural reasons to move carefully. Those reasons don’t yield to a compelling pitch. They yield to a product built to fit the institution’s compliance architecture, procurement workflow, and operational reality.
Fulcher encountered this while scaling RingMD’s government partnerships across multiple jurisdictions. What made those partnerships possible wasn’t just the quality of the telehealth services product. It was that the product had been built to deliver on those requirements, not adapted to them after the fact.
The Pre-Build Discovery Process Justin Fulcher Recommends
Fulcher treats pre-build discovery as a core part of product development, not a sales activity that runs in parallel.
The first step is mapping the decision chain. The person who responds to an initial outreach, the person who evaluates the product, and the person who approves the contract are frequently different people with different priorities. Founders who don’t understand that structure tend to build relationships in the wrong direction.
The second step is understanding budget and procurement timelines. Government agencies and institutional health systems operate on budget cycles fixed well in advance. A founder approaching a government client mid-fiscal year, without a procurement vehicle in place, may be looking at a 12- to 18- month lead time. That’s manageable if you know it going in.
The third step is finding an internal champion early. Institutions adopt technology more readily when someone inside has a stake in the outcome. That person doesn’t have to be a senior decision-maker, but they need to be credible enough to advocate internally. Founders who develop that relationship before the product is finalized have a different experience of the institutional sales process than those who don’t.
The fourth step is building compliance requirements from the start. In government healthcare and federal contracting, compliance architecture can’t be added to a finished product. FedRAMP authorization requires a platform built to specific security standards and cleared through independent audits. Designing first and attempting to qualify for federal deployment afterward is significantly harder than building to those standards from the beginning.
What Fulcher Learned Inside the Defense Department
Fulcher’s perspective on institutions isn’t only the view of a vendor selling into them. He has also served his country from inside them. Originally from South Carolina, Fulcher studied nonproliferation and terrorism studies at the Middlebury Institute of International Studies and is completing a doctorate in international relations at Johns Hopkins. In 2025, he spent roughly six months in federal service in Washington. He started at the Department of Veterans Affairs before moving to the Department of Defense, where he served as a senior advisor to Defense Secretary Pete Hegseth, part of a new leadership team at the department.
He joined as a founding member of the government efficiency effort launched under President Trump, with a focus on identifying outdated processes and recommending where they could be improved. At the VA, his approach was deliberate. He spent much of his time interviewing staff about how the agency could work better and reviewing programs that were candidates for change.
His time as a public sector advisor gave him a direct view of the internal logic he advises founders to study. From inside the Pentagon and the VA, he saw how budget structures, approval chains, and accountability requirements shape what an institution can adopt and how quickly. The constraints that look like institutional drag from the outside usually have reasons behind them, and Fulcher came away with a clearer sense of what those reasons are and how a technology product has to be built to work within them.
Building Products Institutions Can Actually Use
Justin Fulcher’s view is that building companies for public sector clients is a distinct discipline that founders from consumer or enterprise software backgrounds tend to underestimate. The sales cycles are longer, the compliance requirements are more demanding, and the real-world constraints are more rigid. The founders who do the work to understand those institutions before building for them are, in his experience, the ones who win those contracts.
