Questions founders ask

A CTO is guiding the technical vision: building software where that's needed, improving products for customers, and picking the right tools and technical plans to help the business grow.

My offering specifically covers software and tools research, AI direction, staying on top of software and technology industry trends, and project planning. Translating your business ideas into something a development team can build and maintain sits alongside that.

What it is not is a standard freelance developer role. Think of it as a technical fountain of information: one place to get all the technical understanding you need. If that sounds close to what you need, get in touch.

They solve different problems. A technical lead gives you delivery capacity: someone accountable day to day for shipping. An advisor gives you judgement, which is the set of decisions that shape what gets built and whether it holds up in three years.

If you have a steady queue of work and people already building, you need the lead. If you are deciding what to build, choosing a platform, judging whether the quote in front of you is reasonable, or working out whether your current setup survives growth, hiring for that is slow and expensive, and you may not yet know how to assess the candidates.

In practice the two often run in sequence. I have helped founders define the role, so that their first senior technical hire is the right one.

Usually the opposite. The decisions that are most expensive to reverse (data model, platform, hosting, how customer data is handled) get made in the first few weeks, often by whoever was available rather than whoever was best placed to judge. Unwinding them later costs considerably more than getting them right the first time.

Early-stage work is also lighter. It is often a few meetings about a specific choice, or a short piece of research before you commit budget, rather than an ongoing arrangement.

There is no point at which it is too early. Even with an empty canvas, before anything is built, there is value in talking through your vision and thinking through the business questions that sit behind it, who the product is for, what problem it solves, and how the technical decisions ahead will need to serve that.

First a reply from me, not an automated sequence and not a salesperson. Then a call, usually half an hour to an hour and always free of charge, where you describe your company and goals and I ask questions. The aim of that call is to establish what the actual problem is.

You leave that conversation with something useful whether or not we work together: my honest read on where you are and what I would do first. If the answer is that you do not need me, or that a different specialist would serve you better, I will say so.

If it makes sense to continue, I follow up in writing with what I would propose, so you have something concrete to consider rather than a verbal impression. Start here.

Yes. I work alongside your existing agency or development team from the outside, providing new insights that help their workflows and improve daily technical usage.

That includes research and suggestions aimed at improving project management: where processes are slowing things down, where tools could be better used, and where a different approach would serve both the business and the people doing the work.

The output is insight you and your team can act on.

I am based in the UK and work remotely by default. That covers most of what advisory work involves: calls, written recommendations, reviewing plans and code, and joining the meetings your team already holds.

Remote also keeps things practical. There is no travel time inside the engagement, and short conversations happen when they are needed rather than being saved up for a site visit.

I am happy to travel to in-person meetings when the complexity and detail of the discussions and projects demand it, or simply if that is a preference. I always favour in-person discussion where it helps me connect better with clients and their ideas.

One thing worth raising early if you are outside the UK: I work UK hours. If your team sits in a distant time zone, say so at the start so we can be realistic about overlap.

The honest answer is that it fits in fewer places than the current noise suggests, and in those places it is truly valuable. Where it fits depends heavily on how your business runs today: the processes already in place and the software you already use, more than on the technology itself.

The pattern that works: repetitive work involving language or unstructured information, where being roughly right at speed beats being exactly right slowly, and where a person still checks the output before it matters. Summarising enquiries, drafting first passes, extracting structure from documents, triaging support, searching the knowledge your business has already accumulated.

The pattern that does not work: anything where a wrong answer is expensive and nobody would notice it was wrong. Financial calculations, compliance decisions, anything that reaches a customer unreviewed.

Starting from your existing workflows and systems, rather than from the technology, is the difference between a tool that earns its keep and a costly experiment that goes nowhere. That is the conversation I would want to have before any tool is chosen.

No, and being sold that idea is a reason to look carefully at who is selling it.

What has changed is the cost of producing code. Current tools are good at the mechanical parts: boilerplate, tests, translating between languages, and are well suited to a quick MVP or a starting point. What they cannot do is guarantee the practices you do not know to ask for: security, architecture, scale and maintenance depend on someone involved knowing what good looks like, not on the tool.

What has not changed is everything around that. Deciding what to build. Knowing why the system behaves the way it does at three in the morning. Judging which shortcut is safe and which is a liability. Being accountable when it breaks. Code that nobody on your team understands is a risk on your balance sheet, whoever or whatever wrote it.

The realistic outcome is a smaller share of time spent typing and a larger share spent on judgement, which raises rather than lowers the value of having good judgement available from a professional. If this is a live question for your business, let's discuss it, over social media or through the contact form.

It depends entirely on which tools, on what terms, and how they are configured. That is worth deciding before your team decides it for you by pasting customer data into a free consumer chatbot.

The practical distinction: consumer tiers often reserve the right to train on what you submit, while business and API agreements from major providers generally do not, and come with retention and data-residency terms you can hold them to.

Beyond the contract sit the ordinary questions: what data leaves your systems, who inside the business is allowed to send it, how long it is retained, and whether any of it is personal data under UK GDPR, in which case your privacy notice and lawful basis need to reflect that.

A short written AI policy, alongside one sanctioned tool, solves most of this. Prohibition alone does not work, because people use it anyway and simply stop telling you. If keeping everything in-house is the real requirement, self-hosted open-weight models are the other route, covered further down this page.

Yes. The practice is advisory-led, but I build: bespoke web applications, internal tools, integrations, and the awkward pieces that sit between systems nobody designed to talk to each other.

Which you need depends on the problem. Some engagements are purely advisory, because you have people to build and need the direction to be right. Some are the reverse, because the direction is clear and you need the thing built properly. Many begin as the first and become the second once the shape of the work is understood.

Being able to do both keeps the advice honest. Past projects span a range of tools and technologies, and ongoing internal development work at Ross Gray Digital keeps that experience current, reinforcing the advice rather than sitting apart from it. Examples of delivered work sit in updates.

Yes, in the sense of making sense of it, not in the sense of taking it on to build and maintain long-term. I read and assess: what the system does, what state it is in, what poses real risk as opposed to what is simply untidy, and what it would take to reach a point where changes are safe to make. That gives you a decision backed by evidence, documented both technically and in terms the business side can use, rather than the two extremes founders are usually offered, carry on regardless, or rebuild from scratch.

What follows is a set of suggested next steps, not an open-ended commitment from me to carry them out. Ongoing maintenance and longer-term development are best handled by a development team or agency, and part of the assessment is pointing you towards one suited to the work if you do not already have one.

Rewrites are occasionally the right answer and frequently the expensive one. Working software that is unfashionable is still working software, and stabilising it is usually cheaper than replacing it.

It means the security decisions get made while the system is being designed, when they are cheap, rather than after something has already gone wrong, when they are not.

Concretely: knowing what data you actually need to hold and declining to collect the rest; assuming any input can be hostile; keeping credentials out of the codebase and rotatable; giving every component the narrowest access that lets it do its job; keeping dependencies current and knowing what you depend on; and making sure that when something does go wrong there are logs that tell you what happened.

None of that is exotic and none of it needs a large budget. It needs to be decided early, because retrofitting these properties into a live system holding real customer data is where the cost and the disruption sit. Most breaches are not sophisticated. They are ordinary mistakes that nobody had been asked to think about.

Most of what gets called open-source AI is not open source in the traditional sense, and the distinction matters commercially.

Open source means you get the source and the freedom to use, modify and redistribute it. What is usually on offer with AI models is open weights: you can download the trained model and run it on your own systems, but the training data and much of the process are not published, and the licence may restrict what you do with the result.

That is still useful, and it's the form of "open" AI most businesses actually encounter. Common uses include fine-tuning a model on your own data, avoiding dependence on one supplier for pricing and availability, and meeting regulatory or contractual requirements that data and processing stay in-house.

It depends on the scenario, and the right choice starts from the constraint that actually binds you in that particular one.

If capability on hard tasks is the constraint, reasoning, long documents, code, the leading commercial models are still generally ahead, though the gap to the best open-weight models keeps narrowing, and buying access to a commercial model is a far smaller undertaking than building the capability to host your own.

If control is the constraint, data that cannot leave your infrastructure, regulatory requirements, an isolated environment, then a model you host answers a question no contract can.

If unit cost at volume is the constraint, self-hosting can win, but only beyond the point where steady usage covers the infrastructure and the people running it.

For most businesses the sensible route is to prove the use case on a commercial API first, where setup cost is close to zero, then reassess. Where the model runs is a decision you can revisit later, and that choice only gets easier as the performance gap keeps closing.

Sometimes, and rarely for the reason people expect. Open weights are free to download. Running them is not.

Paying per token is a variable cost with no floor: a quiet month costs nothing. Self-hosting converts that into a fixed cost, capable hardware or rented GPU capacity you pay for whether or not it is busy, plus the people to keep it running, patched and monitored. That last item is the one most often left out of the comparison, and it is usually the largest.

The crossover arrives with high, steady, predictable volume. Below that, the API is cheaper in every sense that matters, including the attention you do not have to spend on it.

The exception is when control rather than cost is the driver. Then the question is not whether it is cheaper, but whether the requirement is real.

Self-hosting removes a handful of risks, most notably a third party seeing or retaining your data, and moves the responsibility for everything else in the system to you.

What it actually solves: your prompts and documents do not leave infrastructure you control, so there is no third-party retention or training question and no supplier terms to police. For regulated data or data-residency requirements, that can be decisive.

What it does not solve is everything you now own yourself. Who is allowed to query the system, what it is permitted to retrieve, whether the model can be induced to surface information it was given for someone else, whether prompts and outputs are being logged somewhere less protected than the source data, and whether the machine it runs on is maintained.

It is easy to end up with a self-hosted setup that is less safe than the commercial API it replaced, by assuming the hard part ended once the model was local.

Three catch people out.

First, "open" licences with conditions attached. Several widely used model licences are not open-source licences at all: they carry usage restrictions, acceptable-use terms, or thresholds above which you need a separate agreement. Others are research or non-commercial only, which rules out the exact use you had in mind.

Second, output and provenance. The licence governs the model. It says little about what you build with it and less about whether the training data was licensed. If your product's value sits in generated output, that is worth understanding before you depend on it.

Third, indemnity. Major commercial providers offer contractual protection against certain intellectual-property claims arising from output. Download a model from a public hub and there is nobody to indemnify you.

None of these is necessarily a blocker. All are cheaper to check now than to discover during due diligence, and that checking is exactly the kind of research I take on, translated into a plain recommendation so the decision is easy to make without reading the licences yourself.

It brings a supply-chain problem of its own, and it is not the one most teams are watching for.

Model files are large downloads from public hubs, and older ways of packaging them can run hidden code when loaded. Where a model comes from and how it is checked matters as much as the model itself, and a familiar-sounding name is not a check. Apply the same care you would to any other software you did not write, since it rarely gets applied.

Then there are risks common to all language models that self-hosting does nothing to remove: it can be tricked into following instructions hidden inside the documents or messages it reads rather than the ones you gave it, given more access than it needs, and its output treated as trustworthy by whatever consumes it.

Think of it as a fast, easily fooled component with access to your network. Treat it as you would anything else with that reach: least access, checked input, checked origin, and no assumption that what it returns is safe.

Yes. It is often the smartest place to start. Not every question needs an engagement behind it. Some need an hour with someone who has seen the problem before.

The format is simple. You bring the situation, a decision you are stuck on, a proposal you are unsure about, confusion around a vibe-coded build, or uncertainty about whether your MVP meets the basics it should, and we work through it. You get my honest read.

If something larger comes out of it, we can talk about that. If it does not, the conversation still did its job.

Founders often postpone these because the question feels too small to justify making contact. The small questions are usually the cheap ones to answer. Ask it.

Yes, and if you are not technical it is one of the highest-value hours you can spend.

What I look for: whether the scope matches what you actually asked for, what has been quietly excluded, whether the estimate is credible for the work described, who owns the code and the accounts at the end, what happens when requirements change, and whether the technical approach is reasonable or simply the one that supplier prefers to sell.

I will also tell you when a proposal is sound. Not every quote needs challenging, and confirming that your supplier is competent and fairly priced is a useful outcome in itself.

You get a written summary you can act on: the questions to put back to them, the clauses worth negotiating, and anything that would make me walk away.

Yes. Build against buy, choosing between platforms, and assessing a supplier are all questions where getting the comparison right up front avoids a costly rollback or a reconsideration down the line.

The work is extensive, comparative research measured directly against your requirements, rather than a survey of the market. What each option does well, where it will constrain you, what it costs to leave, how healthy the product and the company behind it are, what the people already running it say once you get past the marketing, and what the integration effort realistically looks like against the systems you already have.

You get a written recommendation with the reasoning visible, based on what your requirements actually need rather than a generic best-of list. Research you cannot audit is only an opinion in a longer document. You should be able to see how I got there.

Yes, and it changes the quotes that come back.

A vague brief produces proposals that cannot be compared, and hands the supplier control of scope, since every ambiguity resolves in their favour once work starts. A clear specification produces comparable quotes and fewer arguments later.

What that looks like: what the system must do, in order of importance; the non-negotiable constraints; how it fits what you already run; what is out of scope; and what "finished" means in terms you can check yourself.

It stops short of dictating implementation. Tell a competent supplier what the system must achieve and let them decide how, then judge that how. Prescribe both and you pay to have your own inexperience built into the system.

This matters more now than ever. AI tools can turn a clear spec into working code fast, so the spec itself is what actually decides what gets built. A vague brief no longer just risks a bad quote, it risks a system built quickly to the wrong description.

It depends on the type of project and the solution in question, and the approach adapts to fit.

Generally, that means starting broad, drawing on the range of information already out there, then narrowing in on the specifics that matter for your situation, and where it counts, going directly to the people who make or supply it, rather than relying on what others say about it secondhand. That combination is what gets you to the best plan and the right decision, rather than one that only looks right on paper.

What transfers between technologies is not knowledge of a specific tool but a sense of which questions decide the outcome, and of where this kind of thing usually fails.