Fractional CTOYour product is built.
Know if it’s ready.

Dan Markeloff reviews what your AI tools, freelancer or agency built and gives you a written verdict in plain English.

A 30-minute call first, then a fixed price. No commitment before that.

Dan MarkeloffFractional CTO, Valletta Software

Read-only access under NDA. Nothing changes in production.

Your next steps, clearly ranked.

Sample
  1. Fix firstPayment access
  2. KeepExisting architecture
  3. Plan nextTests around payments

Ranked by business risk, not by how hard it is to fix.

Sample. A fragment of a composite report, not a review of your product.

When founders call a Fractional CTO

  • AI-built MVP

    No senior engineer has read it.

  • Agency handover

    You sign off on work you cannot read.

  • Launch is near

    Customers or investors will look.

  • Recurring bugs

  • No technical lead

    Everyone ships, nobody decides.

What is a Fractional CTO?

A Fractional CTO is a senior technical leader who works for your company part time, for a set number of hours a month. They make the technical decisions, review the work of whoever writes the code and answer to you for the result, without the cost of a full-time hire.

At Valletta, that person is Dan Markeloff, and the first step is a fixed-price technical diagnostic of what you already have.

Fractional CTO vs developer, interim CTO and in-house CTO

RoleOwnsDoes not own
DeveloperWriting the code for a task.Deciding what to build. Judging someone else’s work.
Project managerDates, status, coordination.Technical decisions. Code quality.
Fractional CTODecisions, standards, review and acceptance of whoever writes the code.Writing features, by default.
Interim CTOThe same, full time for a fixed period, usually during a handover or a hiring search.Staying on once a permanent lead is in place.
In-house CTOThe same, full time, usually with equity.Starting next week. Independence from the build.

How the Fractional CTO diagnostic works

  1. Your product

    • Code
    • Infrastructure
    • Payments
    • Access
  2. Dan reviews

    Reads the code himself. No automated scan.

  3. Your action plan

    1. Priorities
    2. 30/90-day plan
    3. Debrief call

Fixed price agreed on a 30-minute call. Read-only access under NDA. Typically one to three weeks.

What’s included

Reviewed

  • Code and architecture
  • Infrastructure and deployment
  • Security and access
  • Payment and data flows
  • How your developers work

You receive

  • A written verdict in plain English, ranked worst first
  • A 30-day and a 90-day plan your developers can follow
  • A debrief call with Dan
  • A short note for an investor or a regulator, if you need one

What the diagnostic verdict looks like

Executive verdict

Not ready for paying customers yet. Three fixes stand between you and launch. No rebuild needed.

Composite sample. Findings come from published Valletta audits, not from one client.

  • Why it matters. Anyone who finds the URL can create or change orders.

    What to do. Put authentication on every payment route before launch. About a week for the current developer.

    api/payments/*
  • Why it matters. Customers pay and receive nothing. Refund requests follow.

    What to do. Finish the webhook handlers and test them against Stripe’s test events.

    webhooks/stripe.ts
  • Why it matters. Every past contributor still has them.

    What to do. Rotate every key and move secrets out of the repository. One day.

    .env, 3 files

Sample technical diagnostic

Technical Diagnostic

Verdict page

Sample

Executive verdict

Not ready for paying customers yet. Three fixes stand between you and launch. The architecture and the data model are worth keeping, so a rebuild is not recommended.

Priority findings

9 findings
  1. Fix before launch

    Payment endpoints accept requests with no authentication.

    Anyone who finds the URL can create or change orders. Put authentication on every payment route before launch. About a week for the current developer.

    api/payments/*
  2. Fix before launch

    Stripe webhook handlers are stubs, so paid orders never confirm.

    Customers pay and receive nothing. Refund requests follow. Finish the webhook handlers and test them against Stripe’s test events.

    webhooks/stripe.ts
  3. Fix before launch

    API keys are committed to the repository and live in production.

    Every past contributor still has them. Rotate every key and move secrets out of the repository. One day.

    .env, 3 files
  4. Risky

    Database migrations drifted from the schema running in production.

    The next deploy may fail or silently drop data. Reconcile migrations against production before the next release.

  5. Risky

    A failed refund call can leave money unreturned with no alert.

    You would learn about it from the customer. Add a retry and an alert on failed refunds.

  6. Keep

    Data model and tenant boundaries are sound.

    They will carry the next year of growth. Keep them. No rebuild.

  7. Keep

    Authentication provider is set up correctly.

    Sign-in and sessions are handled by a proven service. No change needed.

  8. Can wait

    Test coverage is thin.

    Bugs in the money paths would reach customers first. Add tests around payments and refunds first, not everywhere.

  9. Can wait

    Several dependencies are behind.

    Nothing exploitable today. Schedule upgrades after launch.

Next 30 days

  1. Rotate every key and move secrets out of the repository. One day.
  2. Put authentication on the payment endpoints and finish the Stripe webhooks. About a week, current developer.
  3. Reconcile the migrations against production, then add tests around the money paths.
Dan MarkeloffFractional CTO, Valletta Software

Composite sample. Findings come from published Valletta audits, not from one client.

Portrait of Dan Markeloff

Who you work with

Dan Markeloff

Fractional CTO, Valletta Software

He reads your code, writes the verdict and is the person on your calls.

  • Twenty-five years in software, cloud and infrastructure. Stanford MBA.
  • CTO for a logistics holding and for an enterprise software vendor.
  • Fractional CTO for three to five companies at a time since 2024.
More background
  • Product lead for a US healthcare SaaS that passed Meaningful Use certification.
  • Took four products from zero to paying users.
  • Built two carrier-grade data centres in Utah and California as chief engineer.
  • Led engineering teams of 6 to 15 people and introduced AI-assisted development in two client teams.
  • English C2. Eleven years working in the US.

Found in other people’s code

Published Valletta work, clients anonymised.

  • Three AI-built products

    Context
    Founders who built with Cursor, Lovable and similar tools.
    Found
    Payment endpoints without authentication. Keys live in production.
    Outcome
    One launch stopped in time. One product cleared to ship as it was.
    See the three audits
  • Cloud migration, video platform

    Context
    Ageing infrastructure moving to AWS with a deadline.
    Found
    A migration nobody on the client side could review.
    Outcome
    Six weeks, no downtime, every step reviewed by a Valletta tech lead.
    Read the migration case

Start with a diagnostic.

It stands on its own. Two optional ways to continue.

Request a call
  • Fractional CTO

    Keep your team. Add technical leadership.

    You have a team or a vendor. You want one person answering for technical decisions.

    • Reviews plans and milestones before you pay
    • Sets standards and acceptance criteria
    • Helps you hire and brief developers
    Scope and limits

    Does not write features. If a fix needs hands, he says so first and you decide who does it. Hours are agreed per engagement.

  • Interim technical owner

    Need a handover? Bring in an interim owner.

    Your vendor is leaving, or your CTO left before the round.

    • Repositories, cloud and pipelines back under your control
    • A written assessment by day 30
    • A runbook and handover to the permanent lead
    Scope and limits

    Commercial terms with the vendor stay with you. Length is agreed per engagement.

Fractional CTO questions, before we talk

Valletta is a company. Dan does the diagnostic and every review, is named in the contract and is not swapped without your consent.

No. Keeping your code and your developers is always an option in the report. No Valletta development is proposed unless you ask.

A developer adds code. A Fractional CTO decides, reviews and answers to you for the result. The comparison above shows who owns what.

Read-only repository and infrastructure access under NDA. You can revoke it the day the diagnostic ends.

By default, no. If a fix needs hands, he says so first and you decide who does it.

A fixed price, quoted on the first call once the size of the codebase is clear.

Founders who want a full-time developer, an equity co-founder or someone on site. For hands-on delivery, see Hire Developers.

Hire Developers

Tell us where you are

Your name, email and five quick answers. Dan reads them himself and replies with times for a 30-minute call.

About you
About the product

No newsletter, no sales sequence. One reply from Dan.