I’ve been building an AI agent that routes requests across multiple LLM providers, OpenAI, Anthropic etc., based on the task. But pretty quickly, I hit a real problem: how do you charge for this fairly?

Flat subscriptions didn’t make sense. Token costs vary by model, input vs output, and actual usage. A user generating a two-line summary isn’t the same as someone churning out 3,000-word articles, yet flat pricing treats them the same.

I looked at a few options for usage-based billing. Stripe Billing has metered subscriptions but you have to build your own token tracking pipeline on top. Orb and Metronome are good, but they’re separate vendors, you’d still need something to capture token data from your LLM calls and pipe it in. What I wanted was something at the gateway level, where the traffic already flows.

I ended up using Kong AI Gateway with Konnect Metering & Billing (built on OpenMeter). The gateway proxies every LLM request, so it already knows the token counts. The metering layer plugs directly into that. No separate vendor, no custom pipeline.

So instead of debating about pricing models, I set up the billing layer. A working system where every API request flows through a gateway, gets tracked, and is priced based on real usage:

1. 🚧 Route requests through AI Gateway
2. 🪙 Tokens get metered per consumer
3. 💵 Pricing gets applied
4. 🧾 Invoice generated

Here’s the whole setup, step by step.

• Set up the gateway
• Step 1: Create a consumer
• Step 2: Configure the AI Proxy
• Step 3: Enable token metering
• Step 4: Create a feature
• Step 5: Create a plan with a rate card
• Step 6: Create a subscription
• Step 7: Validate the invoice
• Step 8: Connect Stripe

The Setup

The billing pipeline has three layers:

Kong AI Gateway proxies the LLM requests. It sits between the app and the provider, handles auth, and this is the part that matters for billing, it logs token statistics for every request.

Konnect Metering & Billing (this is built on OpenMeter) takes those token events and aggregates them per consumer, per billing cycle. It supports defining features, pricing models, and plans on top of the raw usage data.

Stripe collects payment. The metering layer generates invoices that sync to Stripe.

Let me walk through each piece.

Prerequisites

You can do this entirely through the UI or via CLI. I’ll cover both as we go.

1. A Kong Konnect account
2. An OpenAI API key (or any LLM provider key of your choice)

For CLI, you’ll also need decK (v1.43+) installed and a PAT from Kong Konnect.

Set Up the Gateway

Once you log in, click on API Gateway and create one.

I’m using Serverless here. You can choose Self-managed too. Enter the gateway name as ai-service and click Create and configure. Once that’s done, click Add a service and route and fill in:

• Service Name: ai-service
• Service URL: http://httpbin.konghq.com/anything
• Route Name: ai-chat
• Route Path: /chat

CLI

If you prefer the command line, generate your PAT and run:

export KONNECT_TOKEN='your_konnect_pat'
curl -Ls https://get.konghq.com/quickstart | bash -s -- 
  -k $KONNECT_TOKEN --deck-output

This gives you a running Kong Gateway connected to Konnect. It’ll output some environment variables, export them as instructed. You’ll also need:

export DECK_OPENAI_API_KEY='your_openai_api_key'

Then set up the service and route:

_format_version: "3.0"
services:
  - name: ai-service
    url: http://httpbin.konghq.com/anything
routes:
  - name: ai-chat
    paths:
      - "/chat"
    service:
      name: ai-service

Apply it with deck gateway apply. Now you have a route at /chat that we’ll wire up to an LLM.

Step 1: Create a Consumer

You can’t bill anyone if the gateway doesn’t know who is making the request. Consumers are how Kong identifies API callers. Later, we’ll map each consumer to a billing customer.

Add a consumer with a key-auth credential:

You can enter the Key value as acme-secret-key.

Now, you need to add the key-auth plugin to the service so the gateway actually requires authentication:

1. Click on Plugins in the left sidebar
2. Click on New Plugin
3. Select Key Authentication from the plugin list
4. Select Service as the scope or keep it as Global
5. Click Save

CLI

_format_version: "3.0"
consumers:
  - username: acme-corp
    keyauth_credentials:
      - key: acme-secret-key

Then enable the key-auth plugin on the service so the gateway actually requires authentication:

_format_version: "3.0"
plugins:
  - name: key-auth
    service: ai-service
    config:
      key_names:
        - apikey

Apply both with deck gateway apply.

Now every request to /chat must include an apikey header. The gateway identifies the caller as acme-corp, and that identity flows through to metering. Without this step, usage events have no subject. They’re anonymous, and you can’t attribute them to anyone.

Step 2: Configure the AI Proxy

Next, wire the route to an actual LLM. The AI Proxy plugin accepts requests in OpenAI’s chat format and forwards them to the configured provider.

1. Navigate to Plugins
2. Click on New Plugin
3. Select AI Proxy from the plugin list

Following the below yaml for CLI and configure the plugin fields accordingly:

_format_version: "3.0"
plugins:
  - name: ai-proxy
    config:
      route_type: llm/v1/chat
      auth:
        header_name: Authorization
        header_value: Bearer ${{ env "DECK_OPENAI_API_KEY" }}
      model:
        provider: openai
        name: gpt-4o
      logging:
        log_payloads: true
        log_statistics: true

Two things to note here:

log_statistics: true is what makes billing possible. Without it, the gateway proxies requests but doesn’t record token counts. When enabled, it captures prompt tokens, completion tokens, and total tokens on every response. This is the data that metering consumes downstream.

log_payloads: true logs the actual request/response content. This is optional and useful for debugging, but you’d probably turn it off in production for privacy reasons.

Apply with deck gateway apply and test:

curl -X POST "$KONNECT_PROXY_URL/chat" 
  -H "Content-Type: application/json" 
  -H "apikey: acme-secret-key" 
  --json '{
    "messages": [
      {"role": "system", "content": "You are a mathematician."},
      {"role": "user", "content": "What is 1+1?"}
    ]
  }'

You should get a response from GPT-4o. The gateway handled auth, forwarded the request, and logged the token statistics.

If you want to proxy multiple providers (say, OpenAI and Anthropic with automatic failover), you’d use [ai-proxy-advanced](https://developer.konghq.com/plugins/ai-proxy-advanced/) instead with a load balancing config. I stuck with a single provider here to keep the billing walkthrough focused.

Step 3: Enable Token Metering

Now we connect the gateway’s token logs to the metering system.

In Konnect, go to Metering & Billing in the sidebar. You’ll see an AI Gateway Tokens section. Click Enable Related API Gateways, select your control plane (the quickstart one), and confirm.

This activates a built-in meter called kong_konnect_llm_tokens. It uses SUM aggregation on the token count, grouped by:

• $.model : which LLM handled the request
• $.type : whether the tokens are input (request) or output (response)

The grouping matters because LLM providers charge differently for input vs. output tokens. Output tokens are typically 3-5x more expensive because input can be parallelized across GPUs while output generation is sequential, each token depends on all previous tokens. If your metering doesn’t split these, your pricing will be wrong.

At this point, every authenticated request through the AI Gateway generates a usage event that gets aggregated by the meter. But usage alone doesn’t generate invoices. You need to define what’s billable and how it’s priced.

Step 4: Create a Feature

A feature is the link between raw metered data and something that appears on an invoice. Without it, usage is tracked but never billed.

Go to Metering & Billing → Product Catalog → Features and create one:

• Name: ai-token
• Meter: AI Gateway Tokens
• Group by filters:
  • Provider = openai
  • Type = request (this tracks input tokens; you’d create a separate feature for output tokens if you want to price them differently)

The filters narrow the meter to a specific slice of usage. In a real setup, you’d likely create multiple features, one per model, one per token direction, to apply different rates. For this walkthrough, I’m keeping it to one feature to show the flow.

Step 5: Create a Plan with a Rate Card

Plans bundle features with pricing. Go to Product Catalog → Plans and create one:

• Name: Starter
• Billing cadence: 1 month

Add a rate card:

• Feature: ai-token
• Pricing model: Usage Based
• Price per unit: 1
• Entitlement type: Boolean (grants access to the feature)

A note on what “price per unit” means here: 1 unit = 1 token, because the meter SUMs individual tokens. So entering 1 means $1.00 per token, which is way too expensive for real use. I’m using it here because the official tutorial does the same thing: a round number that makes invoice changes easy to spot during testing.

For production, you’d enter something like 0.000003 for GPT-4o input tokens ($3.00 per 1M tokens) or 0.00001 for GPT-4o output tokens ($10.00 per 1M tokens). There’s no “per 1,000” toggle in the UI. You do the math yourself and enter the per-token price as a decimal.

Publish the plan. It’s now available for subscriptions.

Step 6: Create a Customer and Start a Subscription

This is where the consumer from Step 1 connects to the billing system.

Go to Metering & Billing → Billing → Customers and create one:

• Name: Acme Corp
• Include usage from: select the acme-corp consumer

This mapping is what ties gateway traffic to a billable entity. The consumer handles identity at the gateway level; the customer handles identity at the billing level. They’re separate concepts joined here.

Now create a subscription:

• Go to the Acme Corp customer, then Subscriptions → Create a Subscription
• Plan: Starter
• Start the subscription

One important detail: metering only invoices events that occur after the subscription starts. If you sent test requests before creating the subscription, those tokens won’t appear on any invoice. I spent some time confused by this before finding it in the docs.

Step 7: Validate the Invoice

Send a few requests through the gateway:

for i in {1..6}; do
  curl -s -X POST "$KONNECT_PROXY_URL/chat" 
    -H "Content-Type: application/json" 
    -H "apikey: acme-secret-key" 
    --json '{
      "messages": [
        {"role": "user", "content": "Explain what a Fourier transform does in two sentences."}
      ]
    }'
  echo ""
done

Wait a minute or two for the events to propagate, then go to Metering & Billing → Billing → Invoices. Click on Acme Corp, go to the Invoicing tab, and hit Preview Invoice.

You should see the ai-token feature listed with the aggregated token count and the calculated charge based on your rate card. That’s the billing pipeline working end to end, from an API request to a line item on an invoice.

Connecting Stripe

Konnect syncs invoices to Stripe, which handles payment collection, receipts, and retry logic for failed payments. You connect your Stripe account in the Metering & Billing settings, and invoices flow through automatically at the end of each billing cycle.

The result for end users is a transparent invoice showing exactly what they consumed: token count, model, rate applied. Not a flat fee with no breakdown.

## Things I Ran Into

The consumer-customer mapping confused me at first. Kong Gateway has “consumers” (API identity). Metering & Billing has “customers” (billing identity). They’re separate. You create both, then link them. If you skip the consumer or forget to link it, usage events come in but they’re not attributed to anyone billable. Set this up before you start sending traffic.

Input vs. output pricing is a bigger deal than I expected. Output tokens from OpenAI’s GPT-4o cost $10.00/1M vs. $2.50/1M for input. If you use a single flat rate for “tokens,” you’ll underprice output-heavy workloads significantly. Splitting features by token type (request vs. response) and pricing them separately is worth the extra configuration.

The order of operations matters. Specifically: create the consumer and link it to a customer before you start sending traffic you care about billing for. Events that arrive before a subscription exists don’t retroactively appear on invoices.

Where I’d Take This Next

This walkthrough uses a single provider and a single feature. A production setup would look more like:

• Multiple features: one per model per token direction (GPT-4o input, GPT-4o output, Claude input, Claude output)
• Tiered pricing: lower per-token rates at higher usage thresholds to incentivize growth
• Entitlements with metered limits: cap total tokens per month per plan tier, so you can offer Starter (500K tokens), Pro (5M tokens), Enterprise (unlimited)
• AI Proxy Advanced: route across multiple providers with load balancing (lowest-latency, round-robin, or cost-based routing)

The docs for all of these are at developer.konghq.com/metering-and-billing and developer.konghq.com/ai-gateway.

If you’re building an AI agent and thinking about how to charge for it, I’d be curious to hear your approach. Per-token, credits, flat rate? What’s working, what’s not? Drop your thoughts in the comments.

The work I do now as a fractional CTO isn’t new. But it’s different from consulting in ways that matter.
I spent years at EY and Zilker Technology leading technical engagements — architecture direction, team building, platform migrations. Those were full engagements. Temporary, yes, but often 40+ hours a week. I’d make the architecture decisions, but I’d also be neck-deep in backlog grooming, PR reviews, data entry, and playing three roles because the engagement scoped it that way. The high-value work — the decisions, the direction, the “here’s how to architect this and why” — would take maybe 10-15 hours a week. The rest was overhead that cost the client more money but wasn’t the core focus.
I also did work that looked a lot closer to what fractional actually is: technical audits where I’d assess a system in a week and hand back a roadmap. Training drops where I’d come in, walk a team through how to move from Angular 1 to Angular 2, discuss the new paradigm, and leave them to execute. Architecture reviews where the deliverable was a set of diagrams and a handoff, not a six-month residency.
The difference with fractional is that you strip away the noise. No drowning in follow-up. No grooming the backlog or babysitting PRs. It’s the high-level direction, the diagrams, the team handoff, the “I’ve got an hour during lunch — show me what’s not working, I’ll build you a quick prototype, and we’ll walk through it.” The decisions, not the data entry. And the market agrees — demand for fractional C-suite roles grew 68% from 2023 to 2024, with the market now topping $5.7 billion globally.
What changed for me is that I started doing it independently. And the first thing I learned is that the companies who need this the most aren’t always the ones you’d expect.

It’s Not Just Startups

The default narrative is that fractional CTOs exist for pre-seed startups that can’t afford a full-time hire. That’s part of it. But the pattern is broader.
At Hertz, DaVita, Kohl’s, and Chick-fil-A, the highest-value parts of my engagements were always the same: come in, assess, make the critical decisions, build the roadmap, coach the team on how to execute it. The companies had hundreds of engineers. They didn’t need another full-time executive. They needed someone who’d solved their specific problem before and could compress weeks of evaluation into days. Sometimes that turned into a full engagement where I built the team and led the delivery. But the direction-setting — the fractional part — was always the catalyst.
On the other end, I’m working with All That Technology, a home tech services company in the Dallas-Fort Worth metro. A small team — Mike runs the business with a few techs, building something real from a weekend side hustle. He’s competing against established players — companies with 100+ Google reviews, 40+ years in business, Yelp presence, the works. He didn’t need a CTO. He needed someone who could rebuild his Shopify storefront into a service-first conversion engine, set up PostHog analytics to separate bot traffic from real DFW customers, identify $53-119/month in wasted app spend, deliver 15+ strategy documents covering everything from an 8-week growth roadmap to pricing architecture to a 63-piece content calendar, build a growth strategy across Angie’s List, Nextdoor, and BBB, and build him SOPs for what to sell and how — discount structures that double as marketing (10% off for a Google review, another 10% for a social media share), subscription models for recurring revenue, and upsell frameworks so every service call becomes an opportunity to grow the relationship.
In 90 days, that business went from $81/month in revenue to $3,584/month. Average ticket size grew 2.3x. Orders started coming in from surrounding cities — customers finding him organically from towns he hadn’t specifically targeted yet. That growth started with zero ad spend — pure organic and referral. Google Shopping free listings alone are driving 45% of his traffic at $0. The repeat customer base is building — some customers coming back three, four times. We’re now layering in paid channels and the trajectory keeps climbing. The Shopify site generates leads that convert offline. He’s taking market share from competitors who have a decade-plus head start, and he’s doing it by being faster, more responsive, and better positioned online.
As Mike at All That Technology put it: “Your advice and guidance has helped iron out so many kinks — I regularly keep thinking I gotta keep up.” That’s the signal that the engagement is working. He’s not waiting for me to tell him what to do. He’s running harder because the direction is clear and the results are showing up.
That’s not architecture. That’s not CI/CD. That’s GTM strategy, marketing channel optimization, analytics, competitive positioning, pricing, and knowing enough about e-commerce platforms to build what the business actually needs instead of what a dev shop would sell you.

What You’re Actually Buying

The technical decisions — stack, infrastructure, database, cloud provider — are the easy part. I wrote about this in What Does a CTO Actually Do?: any strong senior engineer can make those calls for $100 an hour. That’s commodity work.
What fractional gives you is the focused version of senior technical leadership — the decisions without the overhead. Your team, your offshore devs, your agentic workflows, or your three senior engineers can handle the execution. They need someone to set the direction, make the call on which way to go, and be available when they’re stuck. Not someone sitting in their standups.
What’s harder to buy by the hour:

• Translation between engineering and business. Turning “we have significant technical debt” into “we have a time bomb that will cost us a full sprint to defuse, and here’s why now is cheaper than later.” Making sure neither side is talking past the other.
• Pattern recognition from reps. I’ve done platform migrations, e-commerce rebuilds, real-time system architectures at scale, edge AI deployments, and mobile CI/CD before CI/CD was a thing — back when Chef was just becoming real and infrastructure meant being on a release call, not clicking a button in a cloud console. I’ve watched infra evolve from managing your own AS/400 to Infrastructure as Code with solid APIs and GUIs. When a client hits a problem I’ve seen before, the answer comes from experience across that entire arc, not research. That compresses timelines dramatically.
• Business strategy that a pure technologist won’t give you. Marketing channels, pricing models, growth metrics, positioning against competitors. Not every fractional CTO does this. But the ones who’ve actually built and grown products — not just architected systems — bring a different lens. You might just need help with GTM, PMF, or figuring out which marketing channels are worth your time. I don’t have all the answers, but I’ve been through enough launches, growth experiments, and close-the-deal moments to help with positioning.
• Honest assessment. I spend a lot of time saying “the data doesn’t support this yet.” It’s an unpopular sentence. But when your conversion rate drops 8% over a weekend on 300 visitors, that’s noise, not signal. Knowing when to act and when to wait is worth something.

The Cost Math (Done Honestly)

A senior CTO in a major metro commands $200-300K base plus equity. All-in with benefits, equipment, and the inevitable 2-month ramp-up, you’re looking at $250-350K annually. That’s before they make a single decision.
And that’s the best case. 40% of externally hired executives leave or are terminated within 18 months. When a CTO hire fails, the total cost — recruiting fees, severance, stalled strategy, team disruption, backfill — runs 200-400% of their annual salary. On a $250K hire, that’s $500K-$1M in real damage. And the executive search process takes 3-6 months before you even have someone in the seat.

Fractional eliminates most of that risk. Bad fit? Adjust the engagement or part ways. No severance, no 6-month vacancy, no equity clawback drama.
Fractional doesn’t mean “the same job, fewer hours.” It means a fundamentally different engagement model. Typical fractional CTO rates run $150-500/hour depending on specialization and stage. Here’s what that actually looks like:
A quick distinction that matters here: not every new company is a “startup” in the venture-backed, 10x-growth sense. If you’re building a SaaS product and chasing product-market fit with the goal of raising a Series A, you’re a tech startup. If you started a home services company, a boutique agency, or an e-commerce shop and you’re building a real business that pays real bills — you’re a small business. You might call yourself a startup because you’re new, and you are, but the playbook is different. The technology needs are different. The budget is different. And the kind of help you need from a fractional CTO is different. Both are valid. But conflating them leads to bad advice.
SaaS / tech startup (pre-Series A, 1-5 engineers):
10-15 hours/week at $150-200/hr = $78K-156K/yr. You get the critical architecture decisions, CI/CD setup, mentorship for junior devs, and someone who’s done this before. You don’t get someone sitting in standups or writing JIRA tickets — and you shouldn’t want that at this stage.
Growth-stage tech company (Series A-B, 5-20 engineers):
15-20 hours/week at $200-300/hr = $156K-312K/yr. More hands-on. Sprint planning, hiring process design, vendor negotiations, 1:1s with senior devs. This is where concentrated experience earns its premium.
Non-technical founder / small business startup:
You started a real business — maybe it’s a service company, a local brand, an e-commerce shop. You don’t have engineers and might never need a full engineering team. But you need a website that converts, analytics that separate real customers from bot traffic, a growth strategy, and someone who can build the first version of whatever you need without charging you for a dev team. Project-based or low-hour retainer. A Shopify rebuild might be a fixed project. Ongoing growth strategy might be 5-10 hours/month. The cost is a fraction of hiring a technical co-founder, and you get someone who’s also thinking about your marketing, your analytics, and your unit economics — not just your code.
Enterprise / established companies:
Project-based or retainer. An architecture audit might be 40 hours total. A migration roadmap might be a 3-month engagement at 10 hours/week. A quarterly board-level technical review might be 8 hours per quarter. You have engineers. You need leadership for specific problems, not another VP.
The real savings aren’t in the hourly rate — they’re in the fact that most companies don’t need 2,080 hours of CTO per year. They need 500. Maybe 200. Maybe 40.

What Actually Fills Those Hours

With a startup client, a typical week:
Monday (3 hrs): Architecture review. PR reviews for anything touching infra, auth, or data models. Set technical direction for the week.
Wednesday (3 hrs): 1:1s with senior devs. Unblock technical decisions. Vendor evaluations if needed.
Friday (3 hrs): Sprint planning with eng lead. Technical debt prioritization. Security review.
Async (6 hrs): Slack, code reviews, documentation, incident response if critical.
With a small business client, it’s different:
Weekly check-in (1 hr): Review metrics — real traffic vs bots, conversion rates, revenue trends. Adjust strategy. Talk through what’s working in their outreach and what isn’t.
Async (3-5 hrs): Site improvements, SEO updates, analytics review, growth channel adjustments. Research on positioning. Draft pricing strategies or promotional campaigns.
Monthly: Deeper analysis. Are we hitting the 30/60/90 day targets? Where’s the next growth lever? What needs to change?
With an enterprise client:
Week 1: Deep-dive audit. Interview the team, read the code, map the architecture, identify the three things that will hurt worst in 12 months.
Week 2: Deliver findings. Prioritized roadmap. Specific recommendations with tradeoffs — not a 60-page deck, a working document the team can actually use.
Ongoing (if retained): Monthly check-in. Review progress against roadmap. Adjust priorities. Available for escalations. The team does the work — I make sure they’re doing the right work.

When Fractional Works (and When It Doesn’t)

Fractional is ideal when:

• You’re a SaaS/tech startup pre-Series A with 1-5 engineers
• Your core technical decisions haven’t been made yet
• You need someone who’s done this before — not someone learning on your dime
• You can’t yet justify a $250K+ salary
• Your existing team is capable but needs strategic direction
• You need an architecture audit, migration plan, or technical due diligence
• You’re a non-technical founder who needs a technical translator
• You’re a small business that needs both the tech and the growth strategy
• You’re an enterprise that needs expert judgment for a specific initiative, not another FTE
  72% of CEOs plan to increase their use of fractional executives in 2025. That’s not startup desperation — that’s enterprise strategy.
  Go full-time when:
• Engineering is 10+ people and needs daily leadership
• Technical strategy is your primary competitive advantage
• You’re post-Series B and have the runway
• You need someone in the room for every product decision
• You’re in a heavily regulated industry (healthcare, fintech, defense) where compliance requires constant CTO-level oversight
• The coordination overhead of fractional starts exceeding the cost savings

The Hybrid Path

Most companies don’t need to make this an either-or decision. The smartest ones I’ve worked with start fractional and graduate to full-time when they actually need it.
Months 1-3: Establish architecture, CI/CD, coding standards. Make the big decisions. Build the foundation the team will live on for the next 2-3 years.
Months 4-6: Hire and mentor a senior engineer or eng manager. Transfer institutional knowledge. Start reducing your dependency on me.
Months 7-9: Reduce hours to advisory (5 hrs/week). The team should be self-sufficient for daily decisions.
Month 10+: Transition to board advisor or hire full-time CTO. Your architecture is solid, your team knows how to maintain it.
The fractional CTO can help write the job description for their full-time replacement, interview candidates, and ensure the transition doesn’t lose institutional knowledge. I’ve done this. It works because the incentives are aligned — my job is to make you successful, not to make myself permanent.
Not every engagement follows this arc. Some clients stay on a retainer indefinitely — the 5-10 hours/month of strategic oversight and growth coaching is exactly what they need. Others ramp up temporarily during a fundraise or product launch. The model flexes because the point was never to fill a chair. It was to solve problems.

The Bottom Line

82% of startup failures trace back to leadership and management issues. The question isn’t whether you need senior technical leadership — you absolutely do. The question is whether you need it 40 hours a week.
Don’t hire a full-time CTO because you think you should. Hire one because your engineering org is large enough to need daily strategic leadership. Until then, buy the decisions, not the seat.
And if what you actually need isn’t a CTO at all — if you need someone who can build the site, set up the analytics, figure out your growth channels, coach you on pricing, and help you go from side hustle to real business — that exists too. The title matters less than the outcome. You’ll still do the ground work. You’ll still be the one doing the outreach, handing out the review cards, closing the deals. But having someone in your corner who’s been through it — who can help you figure out what to measure, where to spend, and how to position — that changes the trajectory.
The best people I work with treat these engagements the same way: you’re paying for someone who’s made these mistakes before, so you don’t have to make them for the first time on your dime.
If you’re not sure which model fits, that’s a conversation worth having. No pitch, no pressure — just an honest assessment of where you are and what you actually need.
Book a call: https://cal.com/mdostal/meet