Tor Borgen

At CVM Solutions, Tor owns architecture and delivery for a full-stack Solana transaction suite. The surface covers trading and transaction automation, rank and transaction tooling, token and native-token airdrops, Token-2022 tax distribution, and Solana Pay storefronts. Platforms process 10,000+ daily transactions. Reliability, security, performance, and decentralised delivery are design constraints, held from the first architecture pass. Backend automation cut token-distribution costs by 30%. The system is built for secure on-chain execution and for automation that keeps pace with volume. He runs technical investigation from requirements through implementation, and bridges product, operations, and engineering on the same line.

• Secure on-chain execution with automation sized for real transaction volume
• Trading and transaction tooling, airdrops, and Token-2022 tax distribution
• Solana Pay storefronts with wallet and checkout flows
• 10,000+ daily transactions, with reliability and security in the product requirements
• 30% lower token-distribution cost through backend automation
• Ownership from requirements through implementation across product, operations, and engineering

As Product Owner at Keystone.no, Tor owned the path from product vision to delivery for WITSML, a central data hub, and custom enterprise APIs. Stakeholder alignment, the roadmap, and feasibility sat with him, then implementation across engineering, data, and client teams. The work opened real-time exchange and clearer operational visibility, with interoperability, data integrity, security, and scalability written into the requirements. Five or more integrations shipped on time. Data accessibility improved for 10+ enterprise clients. He stayed hands-on in the solution architecture. The stack behind that delivery included Node.js, Azure APIM, WITSML, REST, and Azure Data Lake.

• Product vision, delivery roadmap, and stakeholder alignment for API-driven integrations
• WITSML, a central data hub, and custom enterprise APIs in one lifecycle
• Node.js, Azure APIM, WITSML, REST, and Azure Data Lake
• 5+ integrations delivered on time
• Broader data access for 10+ enterprise clients
• Hands-on architecture with interoperability, integrity, security, and scale in scope

As Technical Lead and Scrum Master at Keystone.no, Tor led engineering delivery while a legacy React application was rewritten toward a scalable micro-app architecture. Jest and end-to-end testing arrived with the rewrite, so quality moved with the code. Kubernetes adoption improved maintainability and gave deployment a path to scale. Jira automation and workflow changes made planning more predictable and raised the bar on code quality. Scrum ran at team scale. Priorities, dependencies, and delivery expectations stayed visible across the teams doing the work, with the lead still close to the architecture.

• React legacy rewrite toward a scalable micro-app architecture
• Jest and end-to-end testing introduced with the rewrite
• Kubernetes for maintainability and deployment scalability
• Jira automation and workflow improvements for predictability and code quality
• Scrum across teams, with delivery and quality in the same cadence

At Muuh AS, Tor progressed from React development into technical leadership for core applications, customer-facing integrations, and knowledge transfer. He led legacy modernisation onto Azure and Google Cloud: Azure Functions, API Management, oData, PHP, Node.js, and SQL. In operational terms, SQL workloads moved toward Azure, and Linux servers were lifted onto cloud instances. A React Native rewrite then addressed critical NFC failures and recovered the product for customers. Knowledge transfer was part of the lead role, so the team could run the migrated systems and the recovered app with a clear picture of how they were built.

• Technical leadership for core applications, integrations, and knowledge transfer
• Cloud migration across Azure and Google Cloud
• Azure Functions, APIM, oData, PHP, Node.js, and SQL
• SQL workloads moved toward Azure, and Linux servers lifted onto cloud instances
• React Native rewrite that addressed critical NFC failures and recovered the product

Tor takes an integration from the sales conversation to a system people can run. He joins client meetings while requirements are still forming, then reads the documentation and the systems already in place. Data is mapped before scope hardens. That picture becomes a roadmap, a cost, a timeline, and a task breakdown the team can staff. He follows the work through delivery. When the technical reality changes, the plan is adjusted in front of the client, with cost and sequence updated to match. He spars with engineers on the implementation and on the operational work the integration will ask of the people who keep it running.

• Requirements gathered in sales and client meetings
• Documentation and live systems explored before scope is fixed
• Data mapping turned into roadmap, cost, timeline, and tasks
• Delivery followed through, with the plan adjusted when the technical picture changes
• Engineering sparring on implementation and on day-to-day operations

Requests, incidents, and decisions have to stay intelligible as they cross organisations. Tor holds that line for product and technical work. Progress is reported so stakeholders can see it, and critical incidents are communicated while there is still time to act. Commercial promises are translated into engineering capacity. Engineering constraints are translated back into language a client can use. The same ownership shows up at Keystone, across client and data teams, and at CVM, where product, operations, and engineering share one technical owner. Service-operations habits from earlier support leadership sit underneath the product work.

• Requests, incidents, and communication carried across organisations
• Progress and critical incidents kept visible to the people who need them
• Translation between commercial commitments and engineering capacity
• Stakeholder alignment across Keystone client, data, and engineering teams
• The same ownership across CVM product, operations, and engineering

On this work, an API includes its documentation, its critical data requirements, its retention rules, and its validation. Those are specified with the interface and checked as the build proceeds. The setting is enterprise and government-adjacent data handling, where access, integrity, and retention matter as much as the payload. Deliveries are designed with information-security discipline aligned with ISO 27001 practices: documented behaviour, validated data, controlled retention, and a traceable line from the requirement to what production does. Reviewers can see what is stored, how long it is kept, and how a change is validated before it ships.

• API documentation treated as part of the deliverable
• Critical data requirements captured with the design
• Validation and retention designed into the flow
• Enterprise and government-adjacent data handling
• Information-security practices aligned with ISO 27001
• A traceable line from requirement to production behaviour

Small, reliable API jobs belong in Azure Functions. One production pattern is API Management key renewal. When a subscription key must rotate, a function generates the new key, pushes it to the applications that consume the API, and stores it in a secure vault. The workflow stays short and repeatable, inside the platform identity model, with a clear trigger and a clear place for the secret. The same shape fits other narrow API jobs where a timer or an event is enough. Each job stays observable, and the operational surface stays a function the team can reason about on its own.

• Azure Functions for small, reliable API jobs
• APIM key renewal as a single, repeatable workflow
• New key generated and pushed to consuming applications
• Secret stored in a Key Vault–style secure store
• Trigger, distribution, and storage kept in one observable function

Some products are a family of small server functions. On Vercel, Tor shapes that family as incremental functions, each one inside the platform’s serverless limits, composed into a system a team can still explain. Wallet integration follows the same rule. Connection, checkout, and verification each have a place in the flow. The payment path is tightened: fewer round trips, and failure states a user can understand. The surrounding architecture stays intact while that path is optimised. New behaviour is added as another function, with a boundary the next change can respect.

• Multi-function product systems hosted on Vercel
• Incremental functions, each kept inside serverless limits
• Wallet integration laid out across connection, checkout, and verification
• Payment path optimised while the surrounding architecture stays intact
• New behaviour added as its own function, with a clear boundary

Solana Pay is in more than one product Tor has shipped. The flagship pattern pairs the SDK with an on-chain memo, so a payment can be verified afterwards as untampered. The memo rides in the transaction, where the proof can be read again later. Checkout scans a QR code automatically for wallets that support it, and offers a send-to-wallet path when they do not. CVM storefronts use this so commerce stays checkable on-chain, with the same record a reviewer and a customer can both inspect. The flow is reused where a product needs a branded payment step on top of an existing wallet connection.

• Several Solana Pay implementations, with one flagship pattern
• SDK plus an on-chain memo so payment can be verified as untampered
• Automatic QR scan for wallets that support it
• Send-to-wallet fallback when a wallet cannot scan
• CVM storefronts using the same checkable checkout