# Bo Osinupebi — Senior Software Engineer Toronto, Ontario, Canada. Open to senior, lead and selected staff engineering roles: Canadian remote, hybrid and office roles, including relocation; United States relocation subject to sponsorship and work authorization. Permanent or contract. ## Professional stack C#, .NET Framework, ASP.NET Core, Azure, SQL Server, Entity Framework, React, TypeScript, Vite, TeamCity, Octopus Deploy, CI/CD, JWT, code review, and mentoring. ## Condo Control — May 2019 to present - Designed and shipped Azure-hosted .NET REST APIs sustaining 4,000+ requests per minute. - Optimized ORM usage and SQL queries, reducing page load times from 2 seconds to approximately 200 ms. - Engineered Stripe payment workflows supporting $1M+ gross volume in their first six months. - Used idempotency, recoverable states, retries, and reconciliation to keep local records consistent with irreversible processor actions. - Built Playwright and Postman/JavaScript suites covering 700+ test cases, with 90% coverage across feature, code and regression testing. - Integrated NetSuite billing for invoicing, payment tracking, and reconciliation. - Built reusable AI agent skills into a flow that automates Jira tickets from development through testing and sandbox deployment, with conditional manual verification and ticket updates; used MCP tools to inspect New Relic traces. - Reviewed code and mentored junior developers on a shared pricing configuration architecture adaptable across product types; the design was deployed and adopted across the company. ## Independent demonstration [C# payment recovery demonstration](https://github.com/bosinupebi/payment-recovery-demo): synthetic invoices and a fake processor; verifies restart recovery, retries, reconciliation, payload conflicts, and concurrent retries through one service. Contains no employer implementation. ## Education Post Graduate Certificate in Data Science, University of Toronto, 2021. Bachelor of Science in Chemical Engineering, University of Toronto, 2014. ## Links - [Engineering profile](https://osinupebi.com/engineering) - [Resume PDF](https://osinupebi.com/bo-osinupebi-resume.pdf) - [LinkedIn](https://www.linkedin.com/in/bolaosinupebi/) - [GitHub](https://github.com/bosinupebi) - [Payment systems note](https://osinupebi.com/thoughts/persist-intent-before-external-side-effects) - Contact: bo@osinupebi.com # Consulting services ## Payment Reliability Review A focused diagnostic of one payment workflow or integration, covering the paths where processor actions and application records can drift apart. Audience: SaaS teams preparing for a launch, migration, or scale-up—and agencies that need an independent review of a payment workflow. Starting price: CA$2,500 (fixed scope). - Review payment states, webhook handling, retries, idempotency, and reconciliation paths. - Identify high-risk failure cases and gaps in recovery behaviour. - Deliver prioritized findings and a practical remediation plan. - Walk through the findings with the engineering team. https://osinupebi.com/services/payment-reliability-review ## Stripe Integration Build or Rescue Hands-on backend delivery for a defined Stripe, external API, or data integration that needs to be shipped, repaired, or made easier to operate. Audience: Product teams and software agencies with a bounded integration project, stalled implementation, or payment workflow that needs recovery logic. Starting price: From CA$7,500 (per project). - Agree milestones, acceptance criteria, and system boundaries before implementation. - Build or repair integration behaviour, including retries and recoverable state transitions where needed. - Add targeted automated coverage around critical behaviours. - Provide handover notes for the team that will operate the system. https://osinupebi.com/services/stripe-integration-rescue ## Reconciliation and Quality Automation Practical SQL, API, and test automation that helps teams find mismatches, reduce repetitive checks, and protect critical workflows as they change. Audience: Engineering and operations teams spending too much time reconciling records, investigating mismatches, or repeating release checks. Starting price: From CA$1,500 (per month). - Map the current reconciliation or quality-control workflow. - Automate high-value checks across application, processor, and reporting data. - Add regression coverage for the business behaviours that matter most. - Provide a prioritized plan for ongoing reliability improvements. https://osinupebi.com/services/reconciliation-automation # Thoughts ## The Implementation in Your Head Is Not the Specification Added to this website: 2026-10-04 https://osinupebi.com/thoughts/the-implementation-in-your-head-is-not-the-specification People get a bad output from an LLM and immediately blame the model instead of reviewing what they actually gave it. Even with thinking machines, the old rule still applies: garbage in, garbage out. LLMs are also a little like the genie in the bottle or the Midas touch: be careful how you phrase the wish. You may get exactly what you asked for and still not get what you wanted. If the model followed your prompt but missed the outcome you had in your head, that outcome was never part of the specification. The implementation in your head does not become part of the prompt by magic. ## Software Is Becoming a Manufacturing Process Added to this website: 2026-10-01 https://osinupebi.com/thoughts/software-is-becoming-a-manufacturing-process I think software companies will increasingly resemble manufacturing companies. Established patterns, clear specifications, and automated quality controls will let agents produce and ship features through an assembly line. In that world, insisting that a developer personally understand every implementation detail becomes a silly measure of quality. A production manager doesn’t need to explain every machine component to establish that the product meets its specification. The engineering work moves toward designing the process, defining the constraints, and building reliable ways to verify the output. If our validation cannot establish enough confidence to ship, improve the validation. “A human wrote it and understood it” was never a guarantee that it worked. ## Understanding Every Line Is Not the Same as Proving Correctness Added to this website: 2026-10-01 https://osinupebi.com/thoughts/understanding-every-line-is-not-the-same-as-proving-correctness I think this take about rejecting AI-written PRs unless the developer understands every implementation detail is silly. Some of these arguments increasingly sound like developers trying to protect their relevance. We already build on layers of abstraction we don’t fully understand. Follow that argument far enough and you shouldn’t submit a PR unless you can explain the bytecode it produces. The focus should be on why the change is needed, what guarantees we have that it works, and what evidence we have that existing behaviour is preserved. Understanding the implementation helps establish those things. But “I understand every line because I wrote it” has never been proof of correctness. ## Make It Cheap to Be Wrong Added to this website: 2026-10-01 https://osinupebi.com/thoughts/make-it-cheap-to-be-wrong Human progress is an evolutionary process of conjecture, criticism and error correction. We generate explanations, test them against reality, discard what fails and build on what survives. Thinking machines dramatically expand our capacity to do this. But this is not an argument for random experimentation. The best conjectures are guided by good explanations: explanations that are hard to vary without breaking their ability to account for what we observe. Experimentation matters because it allows us to test those explanations and discover where they are wrong. The mistake is assuming we already know which uses of compute, tokens or energy are worthwhile. Value is often only obvious after the experiment runs. What looks frivolous, inefficient or wrong today may contain the explanation that unlocks something important tomorrow. The goal should therefore be abundance: cheap energy, abundant compute and widely accessible intelligence. Abundance lowers the cost of being wrong, making it cheaper to test better explanations, correct errors and discover new knowledge. Trying to eliminate every mistake by restricting experimentation risks destroying the very mechanisms that produce progress. Preserve error correction, reward good explanations and make it cheap to test them. ## Intelligence Should Be Abundant Added to this website: 2026-10-01 https://osinupebi.com/thoughts/intelligence-should-be-abundant I think I’m an AI accelerationist. When confronted with thinking machines, some people’s first instinct is to impose as many restrictions as possible, then appoint themselves arbiters of what constitutes a worthwhile use of tokens. I find that instinct deeply counterproductive. Prescribing what people should be allowed to spend tokens on is not fundamentally different from prescribing what they should spend their own brainpower thinking about. Intelligence is useful precisely because people will find uses for it that no central authority could anticipate. Thinking machines should be treated much like any other capable worker: give them access to the tools and resources they need to do their jobs, while maintaining sensible permission boundaries around critical systems. The goal should be to make intelligence abundant and useful, not artificially scarce because someone has decided which thoughts are worthy of computation. ## Persist Intent Before External Side Effects Added to this website: 2026-10-01 https://osinupebi.com/thoughts/persist-intent-before-external-side-effects When designing payment systems, one of the less obvious challenges is that you are effectively dealing with a distributed system. You cannot run a database transaction across an external HTTP boundary. The moment you call a payment processor, your local ACID guarantees stop at that boundary. The happy path in non-production environments can make the flow seem straightforward, but things become very different when you have an active database serving thousands of requests, experiencing contention, retries, timeouts, and partial failures. The real question becomes: how do you ensure that your internal system state remains consistent and recoverable before and after the external transaction is processed? After spending some time building these systems and encountering bugs that were not immediately obvious, I think the most durable pattern is to persist intent locally before performing the external side effect. Create a durable local entity in a transitional state such as Pending or PaymentPending, commit that state, process the payment, then transition the entity based on the result. You might ask, why not take the payment first and create the entity afterwards? The problem is that this creates a failure window where the payment succeeds but the local write does not. You have now taken the customer's money without necessarily having enough durable application state to reliably recreate or reconcile what the payment was for. This is essentially a state-machine approach, often combined with patterns such as the Transactional Outbox and idempotent processing. The principle is simple: persist intent first, perform the external side effect second, then make every subsequent state transition recoverable and idempotent. ## Code Generation Is Becoming a Commodity Added to this website: 2026-10-01 https://osinupebi.com/thoughts/code-generation-is-becoming-a-commodity Code generation has largely been commoditized. Where frontier models still excel is depth, taste, and judgment. Time will tell whether there remains a meaningful difference between the “slop” generated by frontier models and everyone else, and whether that difference is large enough for them to continue commanding a premium. ## The Strongest Tests Validate the Whole System Added to this website: 2026-10-01 https://osinupebi.com/thoughts/the-strongest-tests-validate-the-whole-system When shipping code or fixing bugs, my biggest concern is enforcing invariants across the entire application so logic does not drift or behaviour change unexpectedly. Backend coverage alone is not enough because users can take valid actions in unexpected sequences. Interfaces enforce structure, but not consistent business behaviour across implementations. Shared domain rules, contract tests, state transitions, and factories provide important code-level safety nets, but automated end-to-end tests offer the strongest protection by validating that the application still behaves correctly as a complete system. ## Agent Underemployment Added to this website: 2026-10-01 https://osinupebi.com/thoughts/agent-underemployment Using LLMs for only code generation is agent underemployment. ## Efficiency Even in Failure Added to this website: 2026-10-01 https://osinupebi.com/thoughts/efficiency-even-in-failure On efficiency, even in failure: When executing logic through smart contracts, the amount of code run is directly proportional to the cost of execution. This means that, when chasing an arbitrage opportunity, if the competition lands their transaction ahead of yours in the block, your transaction might end up costing as much in failure as it would have in success. To mitigate this, it is advisable to add checks throughout the logic to prevent execution from going on longer than necessary.