DEV Community: Kevin Smith

Technical Due Diligence: The Three Questions Investors Really Ask

Kevin Smith — Fri, 30 Oct 2026 07:23:10 +0000

Technical due diligence is often treated as a formality, a checklist item after the term sheet handled by whichever engineer has a spare afternoon. That is a mistake for investors, who inherit risks no pitch deck shows, and for founders, who miss a chance to turn engineering maturity into an advantage.

I recently read iAastha's article on technical due diligence for investors, and its framing is the clearest I have seen. Good diligence is not a code-quality audit for its own sake. It answers three questions that map directly to investment risk.

The three questions

Can the product scale with the growth the business plan assumes?
Can the team maintain and extend it, including people not yet hired?
How much lives in one person's head instead of in the system?

Those matter more than any individual code smell. A slightly messy codebase from a team that ships fast, tests critical paths and documents decisions is a better bet than pristine code with no tests, no CI and one founder who is the only person able to deploy.

Red flags worth weighting

No automated tests on paths that touch money or user data (checkout, auth, fund movement), even if overall coverage is low.
A single point of failure in people or access.
Infrastructure costs that will multiply once growth accelerates.

For founders

Prepare weeks ahead. Write down architecture decisions, make deploys boring and repeatable, spread knowledge across the team, and know your cost curve. Diligence then becomes a conversation where you demonstrate control, not a test you hope to survive.

If you are on either side of a funding round, the full piece, Technical Due Diligence: What Investors Actually Need to Know, is a practical framework you can use immediately.

Strangler Fig Pattern: Modernizing One Business Capability at a Time

Kevin Smith — Thu, 29 Oct 2026 10:37:01 +0000

Most enterprises carry at least one system nobody wants to touch and nobody can replace overnight. A full rewrite looks tidy on a slide, but it hides risk until cut-over day, when every undocumented behavior surfaces at once. This is my summary of a walkthrough by the iAastha team on a safer alternative: the strangler fig pattern.

The idea

Martin Fowler described the approach in 2004: gradually create a new system around the edges of the old. Each capability goes through three moves: transform (build the new implementation of one capability), coexist (run old and new behind a routing layer), and eliminate (remove the old path once the new one has earned trust).

The worked example

The article uses a hypothetical account-notification service inside a monolith: password resets, failed-payment alerts and statement-ready messages. Notifications are customer-visible and event-driven, so inputs and outputs are easy to observe and compare, which makes them a good first slice.

Five steps

Draw the boundary and build the seam. Define the capability in one sentence, agree the contract (input event with a unique ID, output message plus delivery record, and a guarantee that one event never produces two sends), then add a facade that initially sends 100 percent of traffic to the legacy path.
Plan coexistence. Keep one system of record per data set, avoid dual writes, make everything idempotent, and run the new service in shadow mode before it sends anything.
Route with a canary strategy. Shift traffic by account cohort rather than random request, so a customer never gets half their alerts from each system. Canary suits moving a capability; blue-green suits releasing new versions of the new service.
Compare behavior before trusting it. Store both decisions per event and compare meaningful fields such as recipient, channel, template and timing. Sort each mismatch into new-service bug, legacy bug customers rely on, or acceptable difference, and agree pass criteria with the capability owner in advance.
Retire the old path on purpose. Keep it warm through one full business cycle, then freeze changes, remove the routing fallback, archive historical data and delete the legacy code and jobs.

Takeaway

Shrink the unit of change until each step is small enough to reverse. Old code left "just in case" keeps costing patches, infrastructure and on-call knowledge, so retirement deserves a checklist and an owner.

The full article, including a traffic-routing simulator and the retirement checklist, is on the original post: https://iaastha.com/insights/blog/strangler-fig-pattern-modernize-one-business-capability-at-a-time/

AI Access Control: Setting Boundaries Before You Connect an AI Tool

Kevin Smith — Thu, 29 Oct 2026 08:52:37 +0000

AI tools are easy to connect and surprisingly hard to take back. A chatbot that can read your shared drive, an agent that can send email, an assistant that can update your CRM: each is useful until it does something nobody expected. The practical fix is not a longer policy document. It is a short, explicit operating boundary, agreed before the tool goes live.

This is my summary of the iAastha team's guide, AI Access Control: How to Set AI Governance Boundaries Before You Connect a Tool.

Why tools need a boundary

Most AI problems inside companies are not dramatic hacks. They are ordinary permission problems. A tool was given broad access because that was faster, nobody wrote down what it was meant to do, and nobody was named as the person who could say no. When something goes wrong, the team cannot answer the basic question: was this tool allowed to do that?

AI-enabled tools raise this risk in two ways. They act on plain-language instructions, so behavior is less predictable than a fixed script. And agentic tools can chain several actions together, so one loose permission can reach much further than expected.

What is AI access control?

It is the practice of deciding, in advance and in writing, what an AI system can see, what it can do, and when a human must step in. It borrows from least privilege: give a system only the access it needs to do its job, and nothing more. It sits inside the wider field of AI governance, the policies, roles and checks that keep AI use safe, lawful and accountable.

The three parts of a boundary

Allowed actions. List every action the tool may take on its own, and be literal. "Helps with support" is not an action; "drafts replies in the helpdesk and saves them as unsent" is. Sort each into view only, draft, edit or execute. Most tools should start at draft and earn more trust over time.
Data access. Start with the workflow, not the system. If the tool summarizes support tickets, it needs tickets, not payroll. Name the systems, folders and fields it can read, and the ones it cannot. Take particular care with personal data, contracts and credentials.
Approval rules. Decide which actions must pause for a human: anything irreversible, anything external, anything that spends money, and anything that changes permissions. Name who approves and how quickly, or people will route around the rule.

Review it with the workflow owner

The card is only as good as the conversation behind it. In a 30-minute review, name the workflow owner, walk one real task end to end, mark each action as view, draft, edit or execute, set approval rules, decide how you will know (logs, a weekly sample, or a named reviewer), and set a review date at least every quarter.

If you are planning to connect AI agents or RAG systems to company data, start with this one-page card. For the full guide and an interactive permission card builder, read the original article on iAastha. iAastha is an AI and software engineering partner for startups and enterprises.