Skip to content
Technology leadership · Enterprise architecture · Commercialization Founder-led · Majority woman-owned
Tell us where you’re stuck
Tell us where you’re stuckGet in touch

01 · The experience behind our work

Responsibility at substantial scale.

Technology & architecture

  • Global enterprisesArchitecture for enterprise-scale consumer IoT, health, banking and hospitality platforms
  • A social networkEngineering leadership at 40 million monthly visitors
  • An early consumer wearableOriginal software platform, built in six months by a five-person team; then the data platform behind its research and the weekly, personalized reports its users received

Commercial

  • One of the largest software companiesWon personally as a customer
  • A global IP-services firmSold through its change from services to SaaS
  • A major-market broadcasterTop salesperson, opening accounts with national brands

Strategy

  • A global consultancyCo-developed its legacy-modernization method and an executive curriculum used with Fortune 100 clients
  • SDA BocconiGlobal Executive MBA education, both founders

02 · Sound familiar?

Where independent businesses get stuck.

None of these starts as a technology problem. Each one costs money, time or customers.

  1. No. 1

    Technology gets approved one request at a time.

    No one holds a view of the whole business: who owns each capability and its data, how work crosses teams and systems, and which dependencies block change.

    The cost. You pay for the same integration work twice, reconcile numbers by hand, and break one operation while fixing another.

  2. No. 2

    What makes you different isn’t written down.

    The capabilities behind why customers choose you have never been made explicit enough to guide investment.

    The cost. Budget goes to plumbing, one-off features and customer exceptions, while the core that makes you competitive stays underdeveloped.

  3. No. 3

    Sales, teams and systems pull in different directions.

    Commitments made in the sale don’t match team responsibilities or system boundaries, and nobody is sure who owns delivery and support.

    The cost. Launches slip, promises become costly exceptions, and rework and support eat the margin.

03 · Why we start at the top

The plan is above the waterline. What sinks it is below.

Say the business needs to become a SaaS company. Mapping it together shows the software has to split into separate services, each with a clear owner, that can change and scale on their own. But a system ends up shaped like the conversations of the people who build it, including the ones that never happen. If every decision still runs through you, sales promises custom work to each customer and a vendor holds the data, the new services grow into the same tangle as the old system.

Most companies find it the hard way: a missed launch, a platform rebuilt twice, a promise nobody can deliver.

Above the waterline: what the plan shows

  • A SaaS launch date
  • Separate services and a new architecture
  • A product roadmap
  • A hiring plan to hit the date

Everything on this list is visible, dated and in the budget.

Below it: what we usually find

  • Every release waits for the same one or two people.So the new services still ship as one.
  • The team doubles to hit the date, from five people to ten.So the possible conversations jump from 10 to 45. Teams stop talking to keep up, and the product splits where they stopped.
  • Teams are split into front end, back end and database.So the new services split the same way, and none can ship on its own.
  • Every team writes to the same database.So no service owns its data, and one change can break them all.
  • Sales closes deals by promising custom features.So every customer ends up on a different version.
  • Pricing, contracts and support still assume one-off projects.So the product launches, but nobody can sell or support it as a subscription.
  • A vendor’s contract controls the code, the hosting or the data.So the plan can’t change what the vendor won’t.
  • The first big customer sends a security questionnaire.So the launch waits until someone can show where their data goes, who can see it, and how you would know.

We chart both, then change them together, organizing the work around who needs to talk to whom. And we keep it flexible, because the first design is rarely the last.

How a company is organized decides part of the design before anyone draws it.

Some designs can’t be built at all, because the people who would have to build them together never talk. Here are three common shapes and what each has already decided. Which one looks like yours?

  • Everything runs through you

    COMPANYSYSTEMS waterline You
    Already decided
    Every system meets in one place: you, or the spreadsheet you keep.
    Can’t be built
    Anything that has to run without you, like services that ship on their own or customers who serve themselves.

  • Three islands

    COMPANYSYSTEMS waterline SalesOperationsServiceCRMSchedulingBilling
    Already decided
    Three systems, each with its own copy of the customer, joined by exports and email.
    Can’t be built
    One view of the customer, or a product that runs across sales, operations and service.

  • The vendor’s house

    COMPANYSYSTEMS waterline VendorVendor’s platformYouYou
    Already decided
    Your data and your roadmap live in the vendor’s platform, on the vendor’s terms.
    Can’t be built
    Anything the vendor won’t build, including a way out.

04 · Direction before AI

AI can’t do what your business needs until someone writes it down.

Without direction, AI is a new hire with no manager: fast, confident and expensive.

  1. Cost 1

    Money spent on the wrong thing, faster.

    Tens of thousands a year on tools and seats that produce work nobody asked for, because nobody wrote down what was needed.

  2. Cost 2

    The wrong model for the job.

    The priciest model on routine work, or the cheapest one where a mistake reaches customers. Without requirements, nobody can tell which is which.

  3. Cost 3

    Trade secrets in public tools.

    Pricing, customer data and plans pasted into public AI by well-meaning staff, with no rules and no record of where they went.

E S W N

What AI needs from you is what your team needed all along.

This is where our work usually starts. It points your people and your tools at the same thing.

  • A north starThe one result that says the business is winning, so every person and tool aims at it.
  • Outcomes and guardrailsWhat counts as success, and what must never happen.
  • Customers and their journeyWho it’s for, and where they get stuck.
  • Requirements in plain wordsWhat to build or automate, for whom, and why.
  • Decision rulesWho decides what, so every piece of AI output has an owner.
  • Data and model rulesWhat may go into which tool, which model does which job, and what it may cost.

Get these right and AI starts doing what the business actually needs. We set them up with you, in plain language your team and your tools can both follow.

And discipline

AI doesn’t replace the discipline. It raises the stakes.

Most technology goes wrong in execution, not for lack of a big idea. AI makes more code, content and change, faster, so it needs the same outer layers and guardrails as everything else.

Teams new to this kind of architecture are often surprised by how much discipline it takes. We bring the discipline, the outer layers that hold it in place, and the numbers that show it’s working and adding value.

  • Every change is tied to a request and checked before it ships, including what AI writes.Rules · acceptance gate
  • The core stays apart from the edges, so a fast change can’t quietly break what makes you different.Rules · magicroot-sbt
  • Data goes only where the rules allow, with a record of every step.Edge · signed requests and a journal
  • What runs, and who can touch it, is written down as reviewed code, ready for an auditor or a security questionnaire.Outside · infrastructure as code

05 · The route

How we work

Our discipline is a process: product decisions first, then the design of your domain, then behavior written down as plain-language tests before any code. The open-source layers that run this site enforce it, so it holds after we leave. When we run your engineering, the routine comes with it: tracked work, numbered releases, controlled access and a monthly report on how it’s going.

  1. Find the core

    Set the north star, then find what customers actually buy from you and who owns each piece and its data.

  2. Draw the line

    Separate the core from everything around it, then decide what to build, buy, reuse or defer within your cash and staffing.

  3. Build the core

    CTO leadership at the level you need. We write down how the core should behave in plain language, build it on outer layers that already run, then hand it over.

  4. Make it sellable and repeatable

    Qualification, pricing, onboarding and security-review answers, so each offer comes from reusable product capabilities instead of starting over for each customer.

  5. Align the organization with the system

    Responsibilities, decision rights and data ownership that match the system, including what AI may see and decide.

06 · Tomshley Labs

This website is the demo.

We don’t only plan systems; we write and run them. The same open-source building blocks run this site and our clients’ systems, and each one is there for a business reason.

We built the outer layers. You build the core.

It’s hexagonal architecture, plainly. The part only you can build sits in the middle. Everything around it connects that core to customers, other systems and servers, and that is where most budgets go. We’ve already built those outer layers, and they run this site.

  • Libraries, not a framework.

    Each block connects through plain conventions, so your core never depends on it.

  • Every outer layer lifts out.

    Outgrow a block and replace it. The core doesn’t change.

  • Hardened over years of regulated work.

    These blocks run in systems that answer to auditors, with documented behavior, a history of fixes and code built to pass security review.

Your core THE PART ONLY YOU CAN BUILD
  • Core: what makes you different
  • Edge: how customers and other systems reach it
  • Rules: the build keeps the layers apart
  • Outside: where it runs, in your name

Every block, layer by layer

  1. In the middle

    Your core

    The part only you can build

    What makes your business different, and the only layer written from scratch. On this site, it is how we take in and answer inquiries.

  2. Edge · Surface

    What customers see and use

    paste-surface paste-elements paste-assetgraph paste

    Everyone you serve can reach what they came for.

    Pages are built on the server and read clearly on any device, for buyers and for the search and AI tools that read on their behalf.

  3. Edge · Runtime

    What answers every request

    boilerplate-jvm reqreply kafka · twilio adapters Swap the adapter. The core doesn’t change.

    No order, request or record is lost or counted twice, and customer details go only where you approved.

    Every request is recorded before anything else happens and handled once, and it stays in systems you control.

  4. Rules · Build

    What keeps the layers apart

    magicroot-sbt CI versioning & publish acceptance gate

    A small change can’t quietly break the business.

    The build keeps your core apart from the outer layers, so either can change without breaking the other. Nothing ships until the customer’s path passes on desktop and mobile, and every release leaves a record.

  5. Outside · Ship & run

    Where it runs, in your name

    base-containers cicd-pipelines workload-templates-k8s root-modules-tf

    It runs in your name, and what you tell customers and auditors holds up.

    Servers, DNS and email settings live as reviewed code in accounts you own, with the history to back up your answers to security questionnaires and audits.

All of it is open source, with no license fee, so your security team can read exactly what runs.

How this site is built Browse the open-source repositories
Tom and Ashley Schena, drawn as an engraving

07 · Chosen on purpose

Why would people who architected Fortune 100 systems work with a business your size?

Because we chose to.

After careers at enterprise scale, we chose to bring that experience directly to independent businesses and the communities they sustain.

That commitment is personal: Tom is a volunteer firefighter, and Ashley is active in the community. We help owners build profitable businesses and retain control of their future.

Guide · Commercial

Ashley Schena · Chief Executive Officer · Co-founder

Leads commercial strategy, pricing, sales and partnerships. Has personally won enterprise customers and sold through a company’s move from services to SaaS.

Guide · Technical

Thomas Schena · President & CTO · Co-founder

Leads product, architecture and engineering, and Tomshley Labs. Has led engineering for global consumer platforms and architected and scaled Fortune 100 systems.

08 · Start here

Start with a conversation.

Tell us what’s in the way. We’ll tell you plainly whether we’re the right people to help.

Tell us where you’re stuck or write to [email protected]