Jaimie Fryer
Helping founders and small product teams prepare for ISO 27001
social
About Jaimie
I am Jaimie Fryer, a strategic engineering leader and founder of Kalvex in Reykjavik. I help teams ship with confidence by building delivery systems that make quality measurable, repeatable, and fast, especially as software becomes more non deterministic with LLM and AI integrations.
At Kalvex, I partner with clients to implement modern QA automation strategies for complex systems, design self service test automation infrastructure that reduces CI feedback time, and provide fractional agile project management to streamline execution from planning to release.
Before Kalvex, I led QA at Controlant, including pharma validation in a highly regulated environment. I grew QA from a small function into a scaled organization, shifted R and D from manual testing to automation first, introduced metrics driven decision making, and helped accelerate delivery without compromising compliance.
My background also includes build and quality engineering across game development and cloud platforms, where I built CI and validation pipelines, improved developer workflows, and strengthened DevOps culture.
I am certified in agile testing and agile test automation through ICAgile, and I hold a Cisco CCNA. I am passionate about governance engineering, practical DevOps, and building cultures where everyone owns quality from idea to production.
Message Me
How can I help you?
Subscribe for Updates
Subscribe to my newsletter to get updates on my latest content.
Meet
ISO 27001 Readiness Chat with Jaimie
Building a startup and facing an ISO 27001 requirement? Join me for a free 30-minute conversation about your goals, customer deadlines and current security practices.
We’ll discuss where you’re starting, what preparation could involve and whether Sinope’s guided approach could fit your team. Bring your questions about scope, evidence and the work ahead.
I’m the founder of Sinope, developing AI-guided ISO 27001 readiness software for small product teams. This is an exploratory conversation, with no obligation to buy. Independent certification audits are a separate process.
1:1 QA Automation and DevOps
Get a practical plan to move from manual testing to automation first delivery with confidence. I have led QA orgs from 2 to 20 plus engineers, built QA tooling teams, and shipped in regulated pharma environments while improving speed and reliability.
In 60 minutes we will assess your current delivery pipeline, test strategy, and team ownership model. You will leave with prioritized next steps, example metrics to track, and a roadmap for CI friendly automation and governance that fits your risk profile.
Blog
Astra Always Finds Something. Make It Stop.
I built a software factory, and somewhere inside it, I created a loop that feels like I shouldn't break out of.
The setup is straightforward enough. Claude writes the code. GPT-6 Astra reviews the pull requests. Before Astra even gets involved, there is a full stack of linters, formatters, and test runners doing their thing, so by the time a diff lands in front of Astra, the cosmetic stuff is already handled. No tabs-versus-spaces debates. No missing newlines. What Astra sees is structurally meaningful code, and what Astra finds are structurally meaningful problems.
That part is working exactly as intended.
The problem is that it never stops.
What the loop actually looks like
Here is the sequence, played out honestly. Claude writes code, opens a pull request, Astra reviews it, finds something real, and flags it. Claude fixes the issue. But fixing the issue means producing more code. More code means a new diff. A new diff means Astra has fresh surface area to review. And Astra, being thorough and not at all shy about it, finds something in the new code too.
Repeat indefinitely.
Every single review round is legitimate. Astra is not nitpicking. When it flags something, it is usually a structural concern, a schema boundary not being respected according to the design, something that genuinely matters. I have not seen Astra go cosmetic on me yet, and I suspect that is partly because the earlier tooling in the pipeline filters that noise out before Astra has a chance to care about it. So the things that make it through to code review are real things.
Which makes the loop harder to break, not easier.
If Astra were padding its reviews with minor style complaints, I could just tune the prompt, tighten the severity threshold, and call it done. But when every flagged item is a real item, you cannot dismiss the third round just because it is the third round. What if the change made in round two introduced something more dangerous than what was in round one? That is not a hypothetical. It is the mechanical reality of how the pipeline works.
The part that humans do differently, without even thinking about it
When I compare this to how a human code review actually works, the contrast is sharp.
A human reviewer reads the entire pull request. They think about it, they consider the design, and they leave their comments. The author addresses those comments and pushes an update. And then, in most functioning engineering teams, there is an unspoken norm: you do not go ham on the second pass. You check that your comments were addressed, maybe catch something genuinely new, but you extend a kind of good-faith trust to the work that was done before. The prior code is not re-litigated from scratch. It is assumed to be trustworthy, at least to the degree that it has already been reviewed and accepted.
Agents do not have that. They do not carry a sense of what has already been vouched for. There is no accumulated trust in prior passes, no cultural norm around reviewer restraint on iteration two. Every diff is a fresh opportunity to find something, and they take it.
I am not saying that is wrong, exactly. In some ways, treating every change with equal scrutiny sounds like the right instinct. The problem is that it is computationally expensive, it burns a significant number of tokens per cycle, and it does not actually close tasks. The loop just keeps running, and nothing gets merged.
Where I am stuck
I have good testing. My mutation testing is solid. The automated checks before Astra are doing their job. The quality infrastructure around this pipeline is not the weak point.
The weak point is that I have not figured out how to encode the human concept of diminishing scrutiny into the process in a way that does not just arbitrarily cap review rounds.
Capping rounds at a fixed number feels like the wrong answer. "You get two passes and then we ship it" is a rule that sounds clean until the third pass would have caught something important. And in a fintech context, where the things that go wrong tend to go wrong in compliance-relevant or security-relevant ways, that is not a trade-off I am comfortable making on a whim.
So the procedural fix of "just limit it" is not satisfying to me. And the structural reason for the loop, that fixes generate new code which generates new review surface, is not something I can eliminate without fundamentally changing how the agent writes its responses. I cannot tell Claude to fix review comments without writing code.
What I can imagine, in theory, is some form of reviewer context that carries forward between rounds. Something that tells Astra: here is what has already been reviewed and accepted, here is what changed since then, focus your attention on the delta and extend reasonable trust to the rest. Something that mimics the human norm of not re-litigating settled ground.
But I do not know if that actually works in practice. I do not know how you prompt for it, how you structure the context window to support it, or whether the model will actually behave that way reliably even if you try. That is the gap I am sitting in.
What I am actually asking
This post is not a tutorial. I do not have the answer. I am genuinely asking the people who are further along on this problem than I am.
If you are running agentic pipelines with automated code review, how are you handling the loop? Are you using severity thresholds to decide when a review comment is significant enough to trigger another round? Are you passing review history forward as context so the reviewer knows what has already been settled? Are you doing something at the orchestration layer that I have not thought of?
And more specifically: how do you encode something like reviewer trust, the human sense that prior-reviewed work does not need to be relitigated from scratch, into a process that runs on models that have no cultural memory of how engineering teams actually function?
I am posting this because I suspect I am not the only founder running into it. The more teams move toward software factories and agentic pipelines, the more this loop becomes a structural problem, not a one-off quirk. The tooling for writing code with AI is maturing fast. The tooling for reviewing AI-written code, at scale, in a way that actually terminates, feels like it is still catching up.
If you have solved this, or even partially solved it, I would genuinely love to hear how. Drop it in the comments or reach out directly. There is something a bit fitting about crowdsourcing the answer to a problem caused by automation, so let's see what the humans come up with.
How We Cut Hosting Costs from $500 to $1.50 a Month by Treating CI/CD as a Quality Engine
We want ISO 27001 certification. The path we thought we were on would cost us around $500 a month in infrastructure before the audit fees even entered the conversation. This was the minimums to get access to the infra partner's certifications. The path we ended up on costs us $1.50. The difference was not a smarter vendor negotiation or a cheaper cloud region. It was a shift in how we thought about code quality control.
This is the SinopeBase story, and I think it is worth telling plainly, because the business case for what we built is hiding inside what looks, on the surface, like a purely technical decision.
From Code Reviews to Controls
The traditional reason teams run heavy code reviews is risk mitigation. You are trying to catch low-quality contributions before they make it into the codebase. That logic is sound, but it carries a hidden assumption: that human reviewers are your best available filter.
When we built SinopeBase, our Supabase-equivalent that lets founders swap from Supabase by simply changing their imports, we made a deliberate choice to shift that risk mitigation away from manual review and toward automated controls embedded directly in the CI/CD pipeline. Not because code reviews are bad, but because the controls we could put in place were genuinely more rigorous than what you could reasonably ask a person to sustain.
The gauntlet we built into SinopeBase includes high levels of code coverage, strict type checking, mutation testing, a CRAP score of six, and code deduplication checks. These are not novel ideas in isolation. What is novel is applying them at a level of intensity that would have been impractical to ask of a human-led review process.
Uncle Bob, someone whose writing essentially took me from intern to lead engineer, has been applying his veteran craft principles to agentic coding, and seeing that connection land in a real project has been genuinely exciting. The discipline he instilled in me around clean code and rigorous standards is the philosophical foundation underneath what we shipped in SinopeBase. It is satisfying in a way I did not expect.
Why This Level of Rigor Became Achievable Now
There is a shift happening that a lot of founders are not fully accounting for yet. Historically, coverage was pinned around 80% because of the 80/20 rule. You got 80% of the value, you left the remaining 20% because pursuing it was not worth the human time it would consume. That calculus made complete sense when the people writing and checking code worked eight-hour days and needed to save their energy for the work that mattered most.
Agents do not work eight-hour days. They do not get frustrated when you ask them to navigate a demanding gauntlet before their code is accepted. They will wait for longer-running tests because they have no reason not to. The 20% you used to leave on the table is now genuinely within reach, not as a theoretical aspiration, but as a practical daily reality.
This is what I mean when I talk about the shift from batch production to a code factory. Every change used to feel like a batch process: a developer writes code, a reviewer reads it, feedback loops back, another human checks it. Now you can have an assembly line for code that never stops, with CI/CD as the Lean Andon cord that pulls the line when something does not meet the standard. The volume of code is no longer the constraint. Quality control is.
For SinopeBase specifically, this meant we could architect a project with genuinely high standards baked in from the start, without the overhead of a large human review team, because the pipeline itself was doing the work that team would have done, and doing it more consistently.
The Business Case That Emerged
Here is the part that surprised even me when I started doing the arithmetic.
We originally looked at getting ISO 27001 through Supabase. The cost was around $500 a month. By building SinopeBase the way we did, using Bun and our preferred libraries and frameworks, tailoring the output to suit how we actually work, and applying the technique that Anthropic implemented in its Bun Zig->Rust migration as a starting point, we brought that infrastructure cost down to $1.50 a month.
That is not a rounding error. That is a fundamentally different financial situation.
The controls we put into SinopeBase were not just an engineering preference. They were the mechanism that made a secure, audit-ready codebase achievable at that price point. You cannot shortcut your way to ISO certification. The evidence has to be there. The controls have to be real. But if your pipeline is doing the enforcement, the cost of maintaining that evidence does not scale linearly with the size of your team or the volume of your output.
When we eventually pass our ISO certification, the cost saving of roughly $498 a month will pay for it, over the course of a year, effectively fund the audit and certification fees themselves. The quality investment pays for the compliance milestone. That is the business win, and it is a direct consequence of the engineering decision we made at the start.
What This Looks Like in Practice
SinopeBase is open source and MIT licensed. The CI/CD configuration is deliberately designed to be something a vibe coder can pick up and drop into their own project. You do not need to reverse-engineer how it works from first principles. You drop the files in, you make sure your containers are accounted for, and you inherit the gauntlet.
The specific controls running in that pipeline include:
- High code coverage, well above the 80% that used to be the comfortable ceiling
- Type checking to catch issues before they compound
- Mutation testing to verify that tests are actually doing useful work, not just running green
- Code deduplication analysis to keep the codebase clean as it scales
- A CRAP score of six as a quality signal
None of these are individually exotic. Together, at this level of enforcement, they create a standard that is genuinely hard to slip past, which is exactly the point.
The goal was never to replace the judgment of a good engineer. It was to create a system where the quality bar is maintained regardless of who, or what, is contributing code. In an era where agents can generate significant volumes of code continuously, that kind of infrastructure is not a nice-to-have. It is the thing that keeps the output trustworthy.
The Takeaway
We started this project trying to solve a hosting cost problem on the road to ISO certification. What we ended up building was a demonstration that the way we control quality in software projects needs to be rethought from the ground up.
Heavy code review made sense when human reviewers were the best quality filter available. Automated controls embedded in CI/CD make more sense now, not because humans are no longer valuable, but because the tools available to enforce standards have become rigorous enough to carry that load, and they do not clock off at the end of the day. There is still some code review but these days its done before the push, we ask Codex to review Claude and Claude to review Codex because agents are still not trustworthy.
The cost savings are real. The compliance path is clearer. And the codebase is empirically better than what most teams would produce under a traditional review model. That is not a claim I would have made confidently a few years ago. It is one I am comfortable making now, because we have the pipeline to back it up.
Daniel Told Me to Start With One. Here's Why That Single Idea Is Reshaping Sinope.
Daniel showed up at 5:30 AM for us. I wrote about that already. But the reason that morning stuck with me isn't just the gesture. It's what he actually said once we sat down.
His first lesson was simple, almost deceptively so: start with one.
Not one product. Not one feature. One customer. Find a single person with a problem so urgent that they'd accept almost anything to make it stop, and start there. Build everything from that moment. Let that one person teach you what the next hundred people will want.
I've been turning that over ever since.
The Brick and the Fire Extinguisher
Daniel used a metaphor that I haven't been able to shake. He said that when you're looking for your first customer, you're not looking for someone with a stubbed toe. You're looking for someone whose hair is on fire.
And here's the part that really landed: if someone's hair is genuinely on fire, and all you have is a brick, they might still let you try. A brick isn't a fire extinguisher. It isn't even close. But if the alternative is standing there watching everything burn, a brick starts to look a lot more reasonable.
The point isn't that you should sell people a bad solution. The point is that when the pain is real and urgent enough, people will meet you where you are. They'll work with your early, imperfect answer because the problem is too costly to ignore. And while you're helping them, you're learning exactly what the fire extinguisher actually needs to look like.
That distinction between a stubbed toe and hair on fire matters more than I initially gave it credit for. A stubbed toe is annoying. People will tell you about it. They'll even say they'd pay for something to fix it. But they won't change their behaviour, they won't prioritise it, and they won't stick around long enough for you to figure out a real solution. Hair on fire is different. That's the kind of problem that makes someone take a meeting, answer follow-up questions, and tell you honestly when your brick isn't working.
How This Led Sinope to Its ICP
I didn't just absorb Daniel's lesson as a theory. It pushed me to look at what Sinope was actually doing and ask the uncomfortable question: whose hair is genuinely on fire here?
We'd done interviews. We'd talked to consultants. We kept hearing variations of the same thing. The hardest moment in compliance isn't building an ISMS from scratch, though that's genuinely hard. It's sitting in an audit for the first time and realising you're not as ready as you thought you were.
First-time audit founders walk in thinking they've done the work. They've got policies. They've got a governance platform with all the boxes checked green. But then the auditor asks a pointed question, and suddenly the founder's verbal answer conflicts with what's written in the policy. Or two pieces of evidence contradict each other. Or a policy exists that nobody on the team actually remembers implementing.
That's a hair-on-fire problem. The deal is on the table. The audit window is open. And the thing that stands between the founder and closing is a stack of documentation that doesn't quite hold together under scrutiny.
This is where Sinope is focusing. Not on founders who are vaguely thinking about compliance one day. Not on teams that are casually exploring their options. On founders who are staring down their first real audit and realising that ticking boxes and being genuinely audit-ready are not the same thing.
That's the one customer Daniel was talking about. That's the hair-on-fire moment we're building toward. Our "hour one," as I've started calling it, is that founder who's about to learn this lesson the hard way, and who we can actually help before they do.
What "Start With One" Really Means for Early-Stage Founders
I think a lot of founders, myself included at earlier points, treat ICP work as a research exercise. You map out personas, you list industries, you define firmographics, and you end up with a description that technically fits a lot of people but resonates deeply with almost none of them.
Daniel's "start with one" cuts through all of that. You don't define your ICP by reasoning your way to it. You find it by actually helping someone. One specific person, with one specific problem, right now.
The lean canvas, the positioning, the messaging, all of it sharpens when it's grounded in a real interaction with a real person who had a real problem that you helped them with. Even imperfectly. Even with a brick.
For Sinope, that focus has meant getting specific in a way that generic market research never would have pushed us toward. The evidence-consistency problem, the conflicting statements, the governance platform that gives you green checkboxes but doesn't actually prepare you for the conversation in the room, those details came from paying close attention to what first-time audit founders are actually experiencing. Not what we assumed they were experiencing.
Daniel told us to start with one. We did. And what came back wasn't just a customer. It was clarity on what we're actually building and who we're building it for.
That's worth more than any persona deck I've ever put together.
I Met a Mentor Who Got Up at 5:30 AM for Us. He Changed How I Think About Outreach.
I am not someone who gets starstruck easily. I have been building in tech long enough to know that confidence and charisma are not the same thing as substance. But when Daniel Ahmadizadeh showed up to our accelerator session this week, I found myself leaning in from the first few minutes.
Daniel is the founder of CrustData and a mentor in the accelerator I am currently part of. He joined us over video, from what I gather is a significant timezone away from where I am. He was up at 5:30 in the morning to be there. That kind of commitment is easy to talk about and hard to actually do. And yet there he was, sharp, present, and genuinely excited to be in the room with us. That enthusiasm is not nothing. It is actually quite rare, especially on a video call where it is so easy for energy to go flat. His did not.
The thing about a great mentor is that they do not just give you a framework. They give you a framework at the exact moment you are ready to receive it. They answer your questions about why an Ice Cream post is more popular than the rest of your content.
The Term I Had Never Heard Before
Daniel talked about the classic split between inbound and outbound, which most founders are familiar with to some degree. But then he introduced a third concept: midbound.
Midbound is about reacting to specific signals in your target customer's journey. Not waiting for them to find you, and not cold-blasting a list. Something in between. You watch for moments when a potential customer is already in motion, already feeling a pain point, and you use that signal as the reason to start a conversation.
He gave a range of examples: someone posting on a competitor's page, a company making a new hire that signals a shift in their priorities, a public statement that suggests they are evaluating tools. The idea is that these moments are windows. When the window is open, you move. When it is closed, you have probably missed your moment.
I had not heard the term midbound before, but the concept immediately made sense to me. It is what good salespeople have always done intuitively. The difference is that when you name it and make it systematic, you can build it into how your whole team operates.
How I Am Applying This to Sinope
With Sinope, I help founders get audit-ready before a big deal expires. That means my ideal customers are in a fairly specific moment in their journey. They are either realising they need compliance infrastructure for the first time, or something has happened to force that realisation.
When I think about midbound through that lens, the signals become pretty obvious.
Someone saying publicly that mainstream GRC tools are too expensive for where they are right now. A founder posting that they just got asked for security documentation as part of a due diligence process and they are not prepared. A company announcing they have signed a deal with a large enterprise, which in most cases means a vendor selection process is either underway or about to be.
These are not vague indicators. They are moments where someone is already feeling the problem I solve. The conversation I start in that context is not cold. It is timely.
That last one is particularly interesting to me: when a startup closes a significant enterprise partnership, the compliance clock often starts ticking immediately. They may not even know it yet. That is exactly when a brief, relevant outreach makes sense, not because I am pitching at them, but because I genuinely have something useful to say at that specific moment.
What I Took Away
The framework itself is valuable. But what stuck with me most was something harder to put into a slide deck.
Daniel did not phone it in. He was up before most people's alarms had gone off, joining a call across a significant distance, and he brought real energy to it. Not performance. Energy. There is a difference. You can feel it when someone is genuinely glad to be there, and he was.
I think a lot about what it means to show up properly, in my own work and in how I want to run the companies I am involved in. Daniel is a good reminder that enthusiasm is not a soft skill. It is a force multiplier. It makes the knowledge land differently. It makes people remember what they heard.
I am going to be building out a midbound motion for Sinope over the coming months. I know the signals I am looking for now. The goal is to be in the right conversation at the right time, not to be everywhere all the time.
That is a more honest use of energy. Daniel would probably agree.
I Watched Gary Tan Tell Me to Scratch Every Itch. Then I Lost Two Days to a Build Trap.
Gary Tan stood up at Y Combinator and said scratch every itch. Boil the sea. Try everything. I watched the video, nodded along, and thought: yes, exactly, that's the energy I need right now.
So I scratched. And then I kept scratching. And somewhere in the middle of day two, I looked up and realised I hadn't spoken to a single potential customer, hadn't done any real outreach, and had nothing to show for my time except a half-working agentic setup that was supposed to do my market discovery for me.
This is that story. It's not a cautionary tale dressed up as wisdom after the fact. It's more honest than that. I genuinely thought I was being smart.
## The Advice That Set Me Off
To be clear, I don't think Gary Tan was wrong. The instinct to scratch every itch is a good one for founders. You're supposed to stay curious, move fast, follow your energy. The alternative, which is sitting still and waiting for perfect information, is how you stay stuck.
But I'm a solo founder. And for a solo founder, time isn't just a resource. It's the whole game. Every hour I spend building something is an hour I'm not spending talking to people, learning from them, finding the one person or the one problem that makes everything else click into place.
When Gary Tan says "try everything," he's speaking to a room full of teams. I applied it like a solo operator, and I didn't account for that difference. That's on me.
## What I Actually Built, and Why
I'd been thinking about market discovery. Specifically, the part of early-stage founder life where you're clicking through LinkedIn endlessly, trying to find the right people, digging for context before you reach out. It's slow, repetitive work, and it eats hours you don't have.
I came across Paperclip.ai, which promised something genuinely interesting: an agentic team with a singular mission, aligned around your goals. On paper, it sounded like exactly what I needed. Not a company in the traditional sense, more like a team of agents working in parallel, doing the legwork I didn't have time for.
So I set it up. Spent time configuring it, orienting it around my discovery goals, trying to get it to do something useful. And it didn't really work. Not in the way I needed it to, not for what I was trying to do.
At that point, the smart move would have been to step back and do the thing manually. Just do the outreach. Open LinkedIn, send the messages, have the conversations. That's what "do things that don't scale" actually means. It means getting your hands dirty so you understand the problem before you try to solve it.
Instead, I decided the problem was Paperclip, not my approach.
## The Part Where I Made It Worse
So I rebuilt it. I switched to Mastra and started again.
To be fair to myself, there was reasoning behind this. Mastra gave me more control over how the agents were structured. And the thing I was trying to build, a workflow that could save me four or so hours a day of manual LinkedIn work, was genuinely worth building if I could get it right.
But here's what I skipped: I skipped the step where you validate that the thing you're automating is actually the thing that needs doing. I hadn't done enough manual discovery to know whether LinkedIn was even the right channel, or whether the problem was the volume of outreach or something else entirely. I just assumed, and then I built toward that assumption.
Two days in, I had a more sophisticated setup and still no new conversations with potential customers. No connections made. No insight gained. Just a shinier version of the first mistake.
The sunk cost crept in quietly. Once you've rebuilt something, it's harder to admit it still isn't working, because now you've doubled down. That's the actual trap: not the first bad decision, but the loyalty to it.
## What I Should Have Done
This one is simple in hindsight. I should have done the manual work first, long enough to feel the pain of it properly, and only then asked whether automation was the right answer.
There's a useful heuristic buried in all of this, and it's one I think about differently now. Do things that don't scale. Everyone says it. Paul Graham wrote the essay. Every accelerator repeats it. But the corollary that doesn't get said as often is just as important: do things that don't scale until doing them is all you're doing.
That's the signal. When the manual version of a task is consuming so much of your time that it's crowding out everything else, that's when automation earns its place. Not before. Not because the tool looks promising, and not because the concept is elegant.
For market discovery specifically, the manual version has a second benefit that no agent can replicate: you learn things. When you're doing your own outreach, reading your own replies, having your own conversations, you're building a mental model of the space that no automated summary can give you. That model is what helps you find the one. The right customer, the right problem, the right angle. You can't shortcut your way to it.
## Where I Landed
The Mastra setup is actually running now, and I do think it'll save me meaningful time once I'm further along. I'm not writing off the build entirely. But I'm clear-eyed about the sequence being wrong: I built before I understood, and I rebuilt before I accepted failure.
The failure part matters. One of the things I've come to think about automation as a solo founder is that you have to be willing to call it early. If something isn't working after a reasonable amount of effort, the answer is almost never "rebuild it with a different tool." The answer is usually "go do the thing manually and come back to this later."
Failing fast sounds easy. In practice, it requires you to separate your ego from the work, which is harder when you're the only one doing it. There's nobody else to tell you to stop. You have to develop that instinct yourself.
So that's what I'm taking from the last few days. Scratch every itch, yes. But know what you're scratching for. And if the itch turns into a two-day detour with nothing to show for it, have the honesty to call it what it is, let it go, and go talk to a person instead.
Building Software Is Now the Easy Part. Getting Into Regulated Markets Is Not.
Everyone can build something now. That sentence would have sounded absurd five years ago, but here we are. You open Claude, you describe what you want, and the software gets made. The barrier to building has essentially collapsed. And for a certain kind of founder, that feels like the finish line.
It is not the finish line. In a lot of ways, it is just the start of the hard part.
I have been thinking about this a lot lately, because it sits right at the heart of what I am working on with Sinope. The more I sit with it, the more I think most people are looking at the wrong bottleneck. They are optimizing furiously for the thing that is no longer the constraint.
The Bottleneck Has Moved
When building software was genuinely hard, most of the startup conversation was about whether you could actually make the thing. Did you have engineers? Could you ship? Those questions made sense at the time.
Now, building is almost trivially accessible by comparison. The conversation needs to shift. Because what has not changed, and honestly what has gotten more complicated as more products flood into the market, is access to regulated industries.
Think about what it actually takes to sell into fintech, or any regulated sector. You are not just selling a product. You are asking a compliance team, a risk officer, and potentially a regulator to vouch for you. That means evidence. It means documentation. It means being able to demonstrate, clearly and in a format that maps to specific certification requirements, that your product is secure, trustworthy, and fit for purpose.
None of that gets easier just because you built your MVP in a weekend with an AI assistant.
What Regulated Markets Actually Demand
The certification that comes up most often when founders start thinking seriously about enterprise sales and regulated environments is ISO 27001. It is a globally recognized standard for information security management, and it matters enormously in sectors like fintech.
What ISO 27001 really asks of you is not complicated in concept, but it is demanding in practice. You need to show your controls, evidence your processes, and demonstrate that your approach to information security is systematic and ongoing. For a small startup, that can feel like being asked to speak a language you have never learned, in front of an audience that will not be forgiving if you get it wrong.
The audit package is where most founders hit the wall. It is one thing to understand that you need to comply. It is another thing entirely to know what evidence to collect, how to structure it, how to map it against the actual requirements, and whether what you have gathered is genuinely usable or just noise.
That gap, between knowing you need to comply and knowing how to prove it, is exactly where I see founders lose momentum. Some of them slow down significantly. Some give up on regulated markets altogether, which is a real shame, because the opportunity there is significant.
Why Fintech Is the Right Place to Start
Not all regulated sectors are created equal when it comes to openness to change. Pharma and medtech, for example, are deeply regulated and move slowly for good reason. The consequences of getting it wrong are severe, the culture is conservative, and the appetite for modernization from smaller, younger companies is limited. That is not a criticism, it is just the reality of those industries.
Fintech is different. There is a genuine progressiveness in how many fintech companies think about regulation. They are not trying to avoid it, they are trying to navigate it intelligently, and they are often willing to work with newer, leaner partners who can demonstrate they have done the work. They tend to be early adopters. They are more comfortable with change.
That makes fintech the more natural starting point for a startup trying to get into a regulated market for the first time. The door is not open, but it is at least ajar.
What We Are Building With Sinope
The core idea behind Sinope is pretty straightforward: we want to reduce the barrier to entering regulated markets by guiding founders through the process of building their first audit package.
The way we do that is through a guided interview. An AI-driven conversation that asks you the right questions, collects the right evidence, and then maps that evidence against the relevant certification requirements. The output is not just a pile of documents. It is a structured, usable audit package that actually holds up to scrutiny.
The goal is to make this process accessible to founders who are not compliance experts. Because most of them are not, and that is fine. The expertise should not need to live inside your company for you to demonstrate that your product meets the standard. You just need a way to get there that does not require months of consulting fees or a full-time compliance hire on day one.
Starting with ISO 27001 made sense for us because it is both widely required and widely misunderstood at the startup level. It is the kind of certification that opens doors, particularly in fintech, and the kind that founders often defer for too long because they do not know how to approach it.
The Bigger Picture
There is a version of the next few years where the ability to build software becomes entirely commoditized, and the competitive advantage shifts decisively toward the founders who can operate in environments that require trust, accountability, and demonstrated compliance. Regulated markets are going to matter more, not less.
The founders who figure out how to navigate certification early are going to have a meaningful head start. Not because they will have ticked a box, but because they will have built something that can actually operate in the markets where real money flows and real enterprise relationships are forged.
I genuinely believe the access problem is solvable. The process of getting certified does not have to be as opaque or as painful as it currently is. It just needs to be made more structured, more guided, and more suited to the way early-stage companies actually work.
That is the problem I am focused on. And I think the timing is right, because the founders who need this the most are only going to become more numerous as building itself gets easier.
The constraint has moved. The question is whether the tools and infrastructure catch up with it. That is what we are trying to build.