DEV Community: Jude Miracle

Building in public #6: I let AI judge every Ad on my platform. Here's what happened.

Jude Miracle — Mon, 02 Mar 2026 11:00:00 +0000

I use AI to score every ad on my platform. It is helpful most of the time, but sometimes it makes incorrect judgments.

This feature excites me, but it also makes me nervous. When a sponsor submits an ad through Adsloty, the ad is analyzed by AI before the writer sees it. The AI scores how well the ad fits the newsletter's audience, checks the tone, rates clarity, estimates clicks, and gives the writer specific recommendations.

The idea is straightforward: writers should have data to determine if an ad is suitable for their newsletter. They shouldn't have to guess.

However, the reality is more complicated than the idea. I will explain how I built this system, what the prompts look like, and what happens when the AI confidently suggests rejecting a suitable ad.

Why AI analysis at all?

A writer receives an ad request for a software tool. The newsletter focuses on technology, which seems like a good match. However, the ad copy is unclear. The call to action says "Learn more," and the description mentions features that are hard to understand without background information.

The writer must decide what to do with limited information. Some writers handle this well, but most struggle—they are writers, not ad salespeople. They either approve all ads (which can harm their audience) or reject anything that isn’t clearly suitable (which can hurt their revenue).

I aimed to provide them with a starting point. Not a decision, but a place to begin.

The model: Gemini 2.5 Flash

I chose Google's Gemini 2.5 Flash. It’s not the biggest or smartest model, but it is fast, affordable, and good enough for structured analysis.

I made this choice on purpose. This task is about classification and scoring, not creative writing, so I don’t need the most advanced model. Flash does a good job for this type of work, and saving money is important when analyzing every single booking.

let url = "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent";

let body = json!({
    "contents": [{
        "parts": [{ "text": prompt }]
    }],
    "generationConfig": {
        "maxOutputTokens": 4096,
        "responseMimeType": "application/json"
    }
});

The responseMimeType: "application/json" is very important. It tells Gemini to give back data in a structured JSON format instead of regular text. If you don’t use it, you might get responses like "Based on my analysis, I believe this ad would score approximately..." This type of response is not useful for a system that needs to store numbers in a database.

The prompt: smaller than you'd think

Here's the actual prompt I'm sending:

fn build_analysis_prompt(&self, ad_copy: &str, ad_title: &str, writer: &Writer) -> String {
    let subscriber_range = writer
        .subscriber_count_range
        .as_deref()
        .unwrap_or("unknown");

    format!(
        r#"Ad: "{}" - {}
Newsletter: {} subs

JSON format:
{{"fit_score":75,"tone_analysis":"Pro","clarity_rating":"High","estimated_clicks_min":30,"estimated_clicks_max":60,"recommendations":["brief tip","brief tip","brief tip"]}}

Rules: score 0-100, tone 1-2 words, clarity High/Medium/Low, tips 3-5 words max. IMPORTANT: Return RAW JSON only. Do not wrap in markdown or code blocks."#,
        ad_title, ad_copy, subscriber_range
    )
}

That's it. The whole prompt.

My first version was three paragraphs long. It explained Adsloty's business model, described what newsletter advertising is, defined each metric in detail, gave five examples of good and bad ads, and included instructions for edge cases. It was thorough but also slow, costly, and did not produce better results.

I kept cutting unnecessary details. With each version, I removed a sentence and assessed if the quality changed. Most of the time, it didn’t. The model understands ad copy and what a newsletter audience is. I was providing more information than the model needed.

The final prompt is very straightforward: ad title and copy, subscriber count, an example of the exact JSON format I want, constraints for each field, and a clear instruction about the format.

I learned three key things about prompts for structured output:

First, the example output is the most important part. The model replicates that structure faithfully, including field names, types, and shape.

Second, clear constraints prevent errors. Saying "Score 0-100" stops the model from giving a score of 150. "Tone 1-2 words" prevents it from writing long paragraphs. "Tips 3-5 words max" keeps recommendations brief and useful.

Third, I added the instruction "do not wrap in markdown" because I learned this from experience. Even with responseMimeType set to JSON, the model sometimes wraps the response in triple backticks. So, I include that instruction and handle it during parsing. It's a double-check.

Parsing: trust nothing

The model usually returns data in JSON format. Sometimes, it may return something similar to JSON. It can also wrap responses in markdown or cut off mid-word. You need to be prepared to handle all these variations.

fn extract_json_from_response(text: &str) -> &str {
    let trimmed = text.trim();

    // Handle ```
{% endraw %}
json ...
{% raw %}
 ``` wrappers
    if let Some(start) = trimmed.find("```

json") {
        let json_start = start + 7;
        if let Some(end) = trimmed[json_start..].find("

```") {
            return trimmed[json_start..json_start + end].trim();
        }
    }

    // Handle generic ```
{% endraw %}
 ...
{% raw %}
 ``` wrappers
    if let Some(start) = trimmed.find("```

") {
        let json_start = start + 3;
        if let Some(end) = trimmed[json_start..].find("

```") {
            return trimmed[json_start..json_start + end].trim();
        }
    }

    // Raw JSON — the happy path
    trimmed
}

After extraction, I validate every field:

// Clamp fit score to valid range
let fit_score = result.fit_score.clamp(0, 100);

// Validate clarity rating
let clarity_rating = match result.clarity_rating.as_str() {
    "High" | "Medium" | "Low" => result.clarity_rating,
    _ => "Medium".to_string(), // Safe default
};

// Sanity check click estimates
let (clicks_min, clicks_max) = if result.estimated_clicks_min <= result.estimated_clicks_max {
    (result.estimated_clicks_min, result.estimated_clicks_max)
} else {
    (result.estimated_clicks_max, result.estimated_clicks_min) // Swap if backwards
};

I also handle truncated JSON. Sometimes the response gets cut off — a recommendation array missing its closing bracket, or the entire object missing its final brace. Instead of failing, I try to fix it:

// Auto-fix truncated JSON
if !cleaned.ends_with('}') {
    if !cleaned.ends_with(']') {
        cleaned.push(']');
    }
    cleaned.push('}');
}

Is this method a bit unconventional? Yes. But does it work? Yes, it does. In real-life situations, you'll use what the model provides, not what it ideally should provide.

When the analysis runs

There are three triggers:

Automatic, when payment is made. When a sponsor completes their purchase and Stripe sends a notification, the backend starts a background task to run the analysis. This process does not block other tasks the booking is created right away, and the AI results get added when they are ready.

fn trigger_ai_analysis_background(state: AppState, booking_id: Uuid, writer_id: Uuid) {
    tokio::spawn(async move {
        match run_ai_analysis(&state, booking_id, writer_id).await {
            Ok(_) => tracing::info!("AI analysis completed for booking {}", booking_id),
            Err(e) => tracing::warn!("AI analysis failed for booking {}: {}", booking_id, e),
        }
    });
}

If the AI call fails—like a timeout, a rate limit issue, or a bad response—the booking is still valid. The writer will just see the ad without a score. The analysis adds to the information but does not block anything.

A batch job runs every 15 minutes. This background job checks for any bookings that didn't get processed—possibly because the AI was down when the webhook was triggered or due to a timing issue. It looks for bookings without an analysis timestamp and processes up to 10 at a time, waiting 500ms between each call.

// Find bookings that need analysis
let bookings = sqlx::query_as::<_, Booking>(
    r#"SELECT * FROM bookings
    WHERE ai_analysis_timestamp IS NULL
        AND cancelled_at IS NULL
        AND status IN ('pending', 'paid')
    ORDER BY created_at DESC
    LIMIT $1"#
)
.bind(limit)
.fetch_all(pool)
.await?;

Manual trigger. Writers can rerun the analysis on any booking. They might want a new score or the first analysis might have been done before they updated their audience description. Just click a button to get a new analysis.

Three layers. If the first analysis misses something, the second one catches it. If the writer needs a redo, the third layer takes care of it. No booking should go without a score for more than 15 minutes.

What the writer sees

When a writer opens a booking request in their dashboard, the AI analysis is easy to find. It is prominently displayed, not hidden in a tab or behind a "show details" link.

The fit score gets a color:

const getFitScoreColor = (score: number) => {
    if (score >= 90) return "text-green-400";  // Great fit
    if (score >= 80) return "text-blue-400";   // Good fit
    if (score >= 70) return "text-yellow-400"; // Okay fit
    return "text-orange-400";                   // Questionable fit
};

Below the score:

Tone analysis: Professional and Direct
Clarity rating: High
Estimated click range: 45 to 120 clicks

Recommendations:

Make the CTA more specific.
Add social proof.
The tone matches the audience well.

These points help writers decide quickly, in 30 seconds instead of 5 minutes.

Does it actually work?

Most of the time, about 80%, the fit scores of the AI are reasonable. It usually gets the tone right and offers helpful recommendations. For simple cases, like a developer tool ad in a tech newsletter, the AI performs well. It might give a score of 85, say the tone is "Technical, Professional," show high clarity, and provide click estimates that make sense.

The other 20% is where it gets tricky.

When the AI is confidently wrong

I’ve noticed three types of bad scores:

The false positive. A crypto trading platform ad submitted to a personal finance newsletter scored 78. The AI noticed "finance" in both but missed the audience's intent. The newsletter targets people learning to budget, not those interested in trading cryptocurrencies.

The false negative. A well-written ad for a writing tool submitted to a creator economy newsletter got a score of 52. The ad's poetic style led the model to think it was unclear, even though it was perfect for writers. The AI confused creativity with a lack of clarity because it defines clarity as straightforward.

The hallucinated precision. The AI might say "Estimated clicks: 847-1,203" for a newsletter with 5,000 subscribers. It doesn't actually know the newsletter's click-through rate or how engaged the audience is. It produces a number that sounds exact but is completely made up. Confident and useless.

What I did about it

I didn’t fix the AI; I changed the message.

The fit score is just a starting point, not a final decision. The interface says “AI Smart Critique,” not “AI Decision.” The approve and reject buttons are always visible, no matter the score. A score of 40 can be approved, and a score of 95 can be rejected.

I thought about automatically rejecting anything below a certain score, but I’m glad I didn’t. A new writer might be excited to see a 40 because it’s their first paying sponsor. Meanwhile, a writer with 50,000 subscribers might reject a 90 because the brand doesn’t match their values. Context is important, and the AI doesn’t have all the details.

For click estimates, I might add a warning or remove them completely. They are the least reliable part of the analysis and can mislead more than help. A writer seeing “estimated 800 clicks” might approve an ad expecting that outcome, then feel disappointed when it only gets 50.

The recommendations are the most useful part. They are valuable not because they are always correct, but because they give the writer specific points to think about. For example, saying “the CTA could be more specific” helps the writer focus on the CTA instead of just skimming it.

The cost question

Every analysis costs money. Gemini 2.5 Flash is inexpensive just a fraction of a cent per call but it can add up. If Adsloty gets 1,000 bookings a month, that means at least 1,000 API calls, plus retries and manual re-analyses. That's why I chose Flash instead of Pro. The quality difference for this task is small, but the cost difference is large. I also keep the prompt minimal to save costs fewer input tokens mean a lower cost per call.

Right now, the AI analysis costs less than $0.01 per booking. The platform fee for a $100 booking is $10. The AI cost is small compared to that. However, I am monitoring it because if the prompt gets longer or I switch to a more advanced model for special cases, the costs could change.

Here’s what I would do differently

If I were starting over, I would do three things:

First, I would include the newsletter's niche and audience details in the prompt, not just the subscriber count. Currently, the prompt is so short that the model has to guess the audience based only on subscriber numbers. That’s why it gets confused about "finance" audiences. More context in the prompt would cost a few more tokens but would greatly improve the accuracy of the fit score.

Second, I would set up a feedback loop from the start. When a writer approves or rejects a booking, it shows whether the AI’s score was helpful. If writers often approve ads that the AI scored at 50, the scoring is likely wrong. I’m not gathering that data yet, but I should be.

Third, I would be more careful with click estimates. They should probably be ranges based on industry benchmarks, not just numbers from the AI. Or I should remove them until I have real click tracking data to compare.

The honest takeaway

AI features look great in demos and presentations. However, in real use, they often have problems. The model makes errors frequently enough that you cannot rely on it completely, but it is also correct often enough that removing it would make the product less effective.

The key is how you frame it. Think of AI as a helper, not as the one making decisions. It helps writers get started, highlights things they might overlook, and saves time on clear choices, allowing them to focus on the tougher decisions.

If you’re adding AI features to your product, my advice is to focus less on the prompts and more on what happens when the prompts fail. And they will. Regularly. Users will evaluate your product based on how well it deals with failures, not just on how great the best outcomes are.

Next time, I’ll write about the embeddable widget how writers can add a "Sponsor this newsletter" button to their sites and what it took to create a JavaScript widget that works on any website without causing issues.

More soon.

Building in public #5: The dashboard

Jude Miracle — Sat, 28 Feb 2026 11:00:00 +0000

Writers need useful information, not just a simple statement like "you earned $500 this month."

I've been thinking about this a lot lately. Adsloty's booking process works well, and money transfers correctly. But when a writer logs in, what do they see? A list of bookings and a number. That's not enough information.

If you make money from your newsletter by selling ad slots, you need to know more about how it works. Which sponsors return for more ads? Is your average booking amount increasing or decreasing? Are you turning down too many requests? Which months are busy, and which are slow?

Without this information, it's hard to make informed decisions. You can't set better prices if you don't know your conversion rate. You can't plan your schedule without seeing seasonal trends. You can't negotiate with a returning sponsor if you don’t realize they’ve spent $3,000 with you over six months.

So, I created the dashboard I would want if I were running a newsletter.

Revenue analytics

When a writer logs into Adsloty, the first thing they see is a summary of their revenue. It shows not just one number, but the complete picture.

-- Writer revenue stats: one query, all the context
SELECT
    writer_id,
    COALESCE(SUM(CASE
        WHEN status IN ('completed', 'pending', 'processing')
        THEN amount ELSE 0
    END), 0) as total_earned,

    COALESCE(SUM(CASE
        WHEN status = 'completed'
        THEN amount ELSE 0
    END), 0) as available_balance,

    COALESCE(SUM(CASE
        WHEN status IN ('pending', 'processing')
        THEN amount ELSE 0
    END), 0) as pending_balance,

    COUNT(CASE WHEN status = 'completed' THEN 1 END) as completed_payouts,
    COUNT(CASE WHEN status IN ('pending', 'processing') THEN 1 END) as pending_payouts
FROM payouts
WHERE writer_id = $1

You can see all your earnings and balances in one place. Your dashboard shows how much you’ve made, what money is available, and what is still pending. It also compares completed payouts to pending ones, so you can easily understand your financial status.

You can view your earnings by different time periods — this month, last month, or overall — and by each sponsor. This breakdown is useful. If you notice that one company has booked five times in three months, it shows that it's a good relationship to maintain. You might want to reach out with a loyalty discount or offer premium placement. This data helps you make decisions without the platform needing to do it for you.

#[derive(Debug, Serialize)]
pub struct DashboardStatsResponse {
    pub total_revenue: String,
    pub total_bookings: i32,
    pub active_bookings: i32,
    pub pending_bookings: i32,
    pub available_slots: i32,
    pub pending_payout_amount: String,
    pub average_booking_amount: Option<String>,
    pub average_fit_score: Option<f64>,
    pub last_booking_date: Option<String>,
    pub cache_age_seconds: i64,
}

Notice the cache_age_seconds at the bottom. Dashboard stats don’t need to be updated in real-time. I save the combined stats and refresh them regularly. The writer can see how recent the data is, and I avoid overloading the database every time someone updates their dashboard.

Performance metrics

Understanding your revenue is important, but knowing the reasons behind it helps even more. Here are some important metrics that writers should track:

Total bookings over time. Look at trends, not just numbers. Are your bookings going up each month? Did you get more bookings after tweeting about sponsorships? Did they drop in December? The trend is more important than the count.

Average booking value. If your average booking was $150 three months ago and is now $200, your price increase hasn’t hurt demand. If it went down, you might have raised prices too quickly.

Conversion rate. This is often overlooked. Out of every 10 booking requests, how many do you accept? If you reject 80% of requests, your listing might attract the wrong sponsors or your standards may be too high for your audience size. This is valuable information to improve upon.

AI fit score trends. This metric is specific to Adsloty. Each ad gets an AI score before you see it. I can show you the average fit score over time. If it’s going up, you’re attracting the right sponsors. If it’s going down, it might be time to update your niche description.

Most popular slots. Which days get the most bookings? Which newsletter positions sell best? If Tuesday slots fill up but Thursday ones don't, you might want to change their prices or stop offering Thursdays altogether.

The PostgreSQL deep dive

I got a bit technical while calculating these metrics. It was quite challenging to do it efficiently.

At first, I used a straightforward method: I ran a separate query for each metric. For total revenue, I made one query. For average booking value, another. I did the same for month-over-month growth and conversion rate. This method worked, but it required eight database requests to load the dashboard, making it feel slow.

Then I discovered PostgreSQL window functions, which changed everything.

-- Running totals, growth rates, and trends in a single pass
SELECT
    date_trunc('month', b.created_at) as month,
    COUNT(*) as bookings,
    SUM(b.writer_payout) as revenue,
    AVG(b.writer_payout) as avg_booking_value,

    -- Month-over-month growth
    SUM(b.writer_payout) - LAG(SUM(b.writer_payout))
        OVER (ORDER BY date_trunc('month', b.created_at))
        as revenue_change,

    -- Running total
    SUM(SUM(b.writer_payout))
        OVER (ORDER BY date_trunc('month', b.created_at))
        as cumulative_revenue,

    -- Conversion rate per month
    COUNT(CASE WHEN b.status = 'confirmed' OR b.status = 'completed' THEN 1 END)::FLOAT
        / NULLIF(COUNT(*), 0) as conversion_rate

FROM bookings b
WHERE b.writer_id = $1
    AND b.created_at >= NOW() - INTERVAL '12 months'
GROUP BY date_trunc('month', b.created_at)
ORDER BY month

I have one question. I want to calculate running totals, monthly growth, conversion rates, and averages directly in the database. This method is faster than using Rust, where I would have to manually go through data.

Using the LAG() function, I can get last month's revenue to work out growth. The SUM() OVER() function lets me find the running total. The NULLIF function helps avoid division by zero when there are months with no bookings.

I am really thankful that I chose Postgres for this. The query optimizer works really well. What used to take eight queries and 200 milliseconds now only takes one query and 30 milliseconds.

The visual layer

Numbers in a table are helpful. Numbers in a chart tell a story.

I used Recharts for my frontend visualizations. I tried other charting libraries like Chart.js, D3, and Nivo, but Recharts was the best fit for my needs. It works well with React, allows for customization, and is easy to use.

<ResponsiveContainer width="100%" height={300}>
  <AreaChart data={revenueData}>
    <defs>
      <linearGradient id="revenueGradient" x1="0" y1="0" x2="0" y2="1">
        <stop offset="5%" stopColor="#4F46E5" stopOpacity={0.3} />
        <stop offset="95%" stopColor="#4F46E5" stopOpacity={0} />
      </linearGradient>
    </defs>
    <XAxis
      dataKey="month"
      tickFormatter={(val) => format(new Date(val), 'MMM')}
    />
    <YAxis tickFormatter={(val) => `$${val}`} />
    <Tooltip
      formatter={(value: number) => [`$${value.toFixed(2)}`, 'Revenue']}
      labelFormatter={(label) => format(new Date(label), 'MMMM yyyy')}
    />
    <Area
      type="monotone"
      dataKey="revenue"
      stroke="#4F46E5"
      fill="url(#revenueGradient)"
    />
  </AreaChart>
</ResponsiveContainer>

Revenue is shown with an area chart, which highlights trends with a gradient fill. Bookings are displayed as a bar chart, making it easier to compare individual events. The conversion rate uses a line chart to show if it is going up or down.

I have also added a booking calendar view. Writers can quickly see which dates are booked, which have pending requests, and which are available. While this may seem simple, it required bringing together booking data, blackout dates (when the writer is unavailable), and availability settings into one view.

Empty states that don't make you feel bad

This is a small issue that really matters.

When new writers sign up, their dashboard shows no data. They see zero bookings and zero revenue. Every chart is blank. This can feel discouraging, as if the platform is already telling them they are failing.

I focused on improving these empty states. Instead of blank charts, new writers see:

"No bookings yet. Your first one is coming," with a link to check their listing.
The revenue chart shows a note saying, "Your revenue trend will appear here."
The calendar shows available slots highlighted, with a positive note — "You have 12 slots available this month."

There are no sad empty boxes and no "0" in big letters. The dashboard should feel like a starting line, not a report card.

Real-time notifications

When a new booking comes in, the writer should see it right away without refreshing their dashboard.

I thought about using WebSockets for this, but then I realized that I only need one-way communication. The server tells the client about the event, but the client doesn't need to respond back. WebSockets allow two-way communication and are more complicated than I need.

Server-Sent Events (SSE) are a better choice. They use one continuous HTTP connection, where the server sends updates to the client. The client listens for these updates. If the connection drops, the browser reconnects automatically. Every browser supports this with EventSource, so no extra library is needed.

// Backend: SSE endpoint for real-time notifications
async fn notification_stream(
    State(state): State<AppState>,
    auth_user: AuthUser,
) -> Sse<impl Stream<Item = Result<Event, Infallible>>> {
    let stream = BroadcastStream::new(state.notification_tx.subscribe())
        .filter_map(move |msg| {
            match msg {
                Ok(notification) if notification.user_id == auth_user.id => {
                    Some(Ok(Event::default()
                        .event("notification")
                        .data(serde_json::to_string(&notification).unwrap())))
                }
                _ => None,
            }
        });

    Sse::new(stream).keep_alive(
        axum::response::sse::KeepAlive::new()
            .interval(Duration::from_secs(30))
    )
}

// Frontend: three lines to listen
const events = new EventSource('/api/notifications/stream');

events.addEventListener('notification', (e) => {
  const notification = JSON.parse(e.data);
  toast.info(notification.message);
  queryClient.invalidateQueries({ queryKey: ['dashboard'] });
});

When a booking comes in, the writer sees a notification pop up. The dashboard updates automatically, so there is no need to refresh or poll for updates.

The backend sends a signal every 30 seconds to keep the connection alive, preventing proxies and load balancers from closing it due to inactivity.

The sponsor's side

Sponsors need a simple dashboard to check their campaigns:

See all campaigns with their status (active, completed, pending)
View total spending and spending by newsletter
Access booking history with ad performance (once click tracking is available)
Quickly rebook — one click to book the same newsletter again

I made the sponsor dashboard simple on purpose. Sponsors want to know two things: "Did my ad run?" and "Was it worth it?" The dashboard should provide answers to both questions quickly.

// Sponsor booking history — includes writer and newsletter details
let bookings = sqlx::query_as::<_, SponsorBookingView>(
    r#"
    SELECT
        b.id, b.status, b.amount, b.newsletter_date,
        b.ad_title, b.ad_url,
        w.newsletter_name, w.subscriber_count,
        b.ai_fit_score, b.created_at
    FROM bookings b
    JOIN writers w ON b.writer_id = w.id
    WHERE b.sponsor_id = $1
    ORDER BY b.created_at DESC
    "#
)
.bind(sponsor_id)
.fetch_all(pool)
.await?;

What's still missing

I'm being clear about what still needs to be done:

Click tracking. This is the biggest gap. Sponsors want to know how many people clicked their ad. Writers want to show that their audience is engaged. I need to create a system that tracks clicks before sending users to the sponsor's URL. This is not too difficult, but it involves the widget, the booking model, and the analytics pipeline, so I will tackle it in a focused sprint.

A/B testing insights. Eventually, I want sponsors to test two versions of their ad copy and see which one works better. We need click tracking first, so this is on hold.

Audience overlap analysis. If a sponsor books ads in three newsletters, are they reaching the same audience three times or three different ones? This is a complex issue. I have some ideas, but it will come later.

The bugs I found

Building the dashboard revealed three issues in the booking process:

Some payouts showed "pending" indefinitely. The job that processes payouts looked for bookings marked as "confirmed," but some had already changed to "completed" by the time the job ran. As a result, the payout remained stuck.
Approved bookings did not change to "completed" after the publication date. The date comparison used UTC, while the newsletter dates were stored without time zone information. For example, a booking for February 20th in EST was compared to February 20th UTC. Depending on when the job ran, it might miss the deadline.
The dashboard statistics counted refunded bookings in the "total bookings," which distorted the count and made the conversion rate appear incorrect.

All three issues required only one or two lines of code to fix. Without the dashboard highlighting these problems, they could have gone unnoticed.

The hidden advantage of creating analytics is that it encourages you to examine your data, which can reveal flaws in your logic.

Advice for building a marketplace dashboard

Cache your data calculations. Dashboards refresh often, and running heavy queries each time will slow down your database.
Use window functions. If you are calculating trends or totals in your application code, it’s too much work. Let Postgres do it.
Design empty states first. Your first users will see these before they see any data. Make these states feel like an opportunity, not a failure.
Choose SSE over WebSockets for one-way updates. It’s simpler, reconnects automatically, and doesn’t require a client library.
Start building the dashboard early. Don’t wait for user requests. It will help you spot bugs in your system that you wouldn’t find otherwise.

Next, I might write about AI fit scoring in detail. I will cover how the prompts work, whether the scores are useful, and what to do when the AI gives bad advice confidently.

I built a booking system for Newsletter Ads. Here's every decision I made.

Jude Miracle — Fri, 27 Feb 2026 14:33:10 +0000

I created the booking flow today. This marks the shift of Adsloty from being just a backend project to becoming a real product.

In my last two posts, I talked about important but hidden features like authentication and payments. While these are necessary, they aren't what draws people to the platform.

The booking flow is different. This is what users will actually engage with. It’s the process a sponsor goes through to find a newsletter, choose a date, submit their ad, and make a payment. It’s also the experience for a writer when a new booking request arrives in their dashboard, complete with an AI analysis.

If this experience is complicated, then nothing else matters.

What I was aiming for

I wanted booking an ad slot to be as easy as booking a flight. You browse, choose, pay, and you’re done. It shouldn’t feel like filling out a loan application or sending a cold email and waiting three days for a reply.

Adsloty aims to remove the hassle between deciding to sponsor a newsletter and completing the booking. Each extra step, unnecessary form field, or promise of “we’ll get back to you” makes it easier for someone to leave the page.

I designed the process for speed and clarity.

The sponsor's experience

Here's what sponsors see, step by step:

First, they discover. Sponsors look through newsletters grouped by topic—like tech, finance, wellness, or the creator economy—that match their products. Each listing shows key details: the number of subscribers, average open rates, cost per slot, and available dates.

// Newsletter discovery with filters
const { data: newsletters } = useQuery({
  queryKey: ['newsletters', { niche, minSubscribers, maxPrice, sortBy }],
  queryFn: () => newsletterApi.search({
    niche,
    min_subscribers: minSubscribers,
    max_price: maxPrice,
    sort_by: sortBy,
    page,
  }),
});

No vanity metrics and no vague pricing. Everything is clear and easy to understand. A sponsor should be able to evaluate a newsletter in under 30 seconds.

Next is the booking form. After choosing a newsletter, the sponsor selects an available date and fills in their ad details: title, description, call-to-action text, link, and an optional image. That’s all they need to do.

I spent a lot of time deciding which fields to make required. My first version had twelve fields. I cut it down to six. Each field I removed was something I thought was nice to have but would slow people down. You can ask for more information later, but you can't win back a user who left because the form felt like homework.

const bookingSchema = z.object({
  newsletter_date: z.string().min(1, "Pick a date"),
  ad_title: z.string().min(5).max(100),
  ad_description: z.string().min(20).max(500),
  ad_url: z.string().url("Enter a valid URL"),
  ad_cta_text: z.string().max(30).optional(),
  ad_image_url: z.string().url().optional(),
});

First, payment is easy. With one click, the sponsor opens Stripe Checkout. They see exactly what they're paying, confirm the payment, and that’s it. No need to enter card details on my site. I don't have to maintain or secure a custom payment form. Stripe's checkout takes care of everything—this includes PCI compliance, 3D Secure, Apple Pay, and Google Pay. I receive a notification when the payment is confirmed.

The whole process from browsing newsletters to confirming payment can take less than two minutes. That was the goal.

In the future I plan making it a escrow based system.

The writer's experience

The writer's dashboard shows a new booking request. It doesn’t just say "someone wants to buy an ad slot." It provides additional context.

This is where the AI analysis comes in.

When a sponsor submits their ad, the backend sends it to Google's Gemini API along with the newsletter's audience data. Before the writer even looks at the request, the AI has already scored it.:

// AI analysis runs automatically when a booking is created
let analysis = gemini_client.analyze_ad(AdAnalysisRequest {
    ad_title: &booking.ad_title,
    ad_description: &booking.ad_description,
    ad_url: &booking.ad_url,
    ad_cta_text: booking.ad_cta_text.as_deref(),
    newsletter_niche: &newsletter.niche,
    newsletter_audience_description: &newsletter.audience_description,
    subscriber_count: newsletter.subscriber_count,
    average_open_rate: newsletter.open_rate,
}).await?;

// Returns structured data, not a wall of text
// {
//   fit_score: 82,
//   tone_analysis: "Professional, Direct",
//   clarity_rating: "High",
//   estimated_clicks_min: 45,
//   estimated_clicks_max: 120,
//   recommendations: [
//     "CTA could be more specific — 'Start free trial' outperforms 'Learn more'",
//     "Ad copy aligns well with tech audience expectations",
//     "Consider adding a specific metric or social proof"
//   ]
// }

You will receive a fit score between 0 and 100 for your ad. The score is based on tone analysis, clarity rating, and an estimated click range. You will also get three to five specific recommendations.

You don’t have to wonder if an ad is a good fit. Just open the request to see the score, read the recommendations, and decide whether to approve or reject with one button.

Initially, I thought about automatically rejecting ads that scored below a certain level. I chose not to do that. The AI is a tool to help, not a barrier. A score of 40 might be just right for a writer starting out who wants to earn money. A score of 90 might still be rejected if the writer doesn't like the brand. The writer makes the final decision, while the AI provides helpful information.

The state machine

Here's where things became more complex.

A booking is not simply "booked" or "not booked." It has a process. This process must be clear and organized because money is involved in every step.

draft → pending_payment → paid → confirmed → completed
                                           → rejected → refunded
                       → expired
                       → cancelled → refunded

Let me explain each step:

Draft. The sponsor started filling out the form but hasn’t paid yet. They may have gotten distracted or are comparing newsletters. Their booking is still in the system, so they can return to it later.
Pending payment. The sponsor clicked "Book now" and was directed to Stripe Checkout. We are waiting for the payment confirmation.
Paid. Stripe confirmed the payment. The writer gets notified, and we run an AI analysis. The booking appears in the writer's dashboard.
Confirmed. The writer approved the ad. It is locked in for the scheduled date, and a payout record is created with a "pending" status.
Completed. The publication date has passed. Our system marks it as complete and processes the payout to the writer.
Rejected. The writer declined the ad. The sponsor receives a full refund, and the payout record is canceled.
Expired. The writer did not respond within the time limit, so we automatically refund the sponsor.
Cancelled. The sponsor canceled the booking before the writer confirmed it. We process a refund.

Each of these steps triggers different actions—like updating the database, sending email notifications, or processing payouts and refunds. There are rules about which steps can follow others. For example, you can’t go from "completed" back to "draft," and you can’t reject a booking that has already been refunded.

impl BookingStatus {
    pub fn can_transition_to(&self, next: &BookingStatus) -> bool {
        matches!(
            (self, next),
            (Self::Draft, Self::PendingPayment)
                | (Self::PendingPayment, Self::Paid)
                | (Self::PendingPayment, Self::Expired)
                | (Self::Paid, Self::Confirmed)
                | (Self::Paid, Self::Rejected)
                | (Self::Confirmed, Self::Completed)
                | (Self::Confirmed, Self::Cancelled)
                | (Self::Rejected, Self::Refunded)
                | (Self::Cancelled, Self::Refunded)
        )
    }
}

I handle this in the backend. Every status update first checks with can_transition_to. If the transition isn’t valid, it shows an error. There are no exceptions. This one function has likely prevented more bugs than anything else I’ve written for this project.

Notifications at every step

Nobody should be confused about their booking status. So, I created email notifications for each important update:

When the sponsor pays, they get an email: "Your booking is confirmed, waiting for writer approval."
When a writer receives a new request, they get: "New ad request for [newsletter name] — review it now."
When the writer approves the ad, the sponsor gets: "Your ad has been approved for [date]."
If the writer rejects it, the sponsor gets: "Your ad wasn't approved — a refund is on its way."
After the ad completes, the writer gets: "Payout of $X is being processed."
When the payout arrives, the writer gets: "You've been paid."

// After writer confirms a booking
async fn confirm_booking(state: &AppState, booking_id: Uuid) -> AppResult<()> {
    let booking = db::booking::find_by_id(&state.db, booking_id).await?;

    // Validate state transition
    if !booking.status.can_transition_to(&BookingStatus::Confirmed) {
        return Err(AppError::BadRequest("Cannot confirm this booking".into()));
    }

    // Update status
    db::booking::update_status(&state.db, booking_id, BookingStatus::Confirmed).await?;

    // Create pending payout
    db::payout::create_payout_tx(
        &mut tx, booking_id, booking.writer_id,
        booking.writer_payout, &booking.currency, "pending",
    ).await?;

    // Notify the sponsor
    send_booking_confirmed_email(state, &booking).await?;

    Ok(())
}

The emails are straightforward. They explain what happened and what will happen next, without any sales language. When it comes to money, being clear is more important than being clever.

The embeddable widget

I built something this week that I'm really excited about: writers can now add a booking widget directly to their newsletter website.

<!-- Drop this on your site -->
<script
  src="https://adsloty.com/widget.js"
  data-writer-id="your-writer-id"
  data-color="#4F46E5"
  data-button-text="Sponsor this newsletter"
></script>

It creates a button that sponsors can click to view the writer's available dates and pricing. They can start the booking process directly from the writer's site without needing to visit Adsloty. This makes the writer's website a sales page for their ads.

Writers can customize the colors, button text, and placement to ensure it fits seamlessly with their site. I am also tracking impressions, clicks, and conversion rates for each widget, so writers can see how many visitors become sponsors.

What's still rough

I won't pretend it's perfect. The discovery page needs better filters and search options. The user interface works, but it still doesn't feel great. The AI analysis can take a few seconds, so I need to add proper loading states instead of the spinner I added in a hurry.

My analytics are basic. I'm tracking numbers, but I need to present them better. Writers should be able to see trends, compare months, and know which topics generate the most revenue. That's in the works.

But the core loop works

A sponsor can find a newsletter, book a slot, pay, and submit their ad. A writer can review the request using AI analysis, approve it, and get paid automatically after the publication date.

This is the core of the product. Everything else is just added features.

If you run a newsletter and want to try this during the beta phase—or if you are a brand that has found sponsoring newsletters difficult—I would really like to know what you think. What would make this more useful for you?

More updates soon.

I integrated Stripe into a two-sided marketplace. Here's what actually happens

Jude Miracle — Mon, 23 Feb 2026 12:51:02 +0000

I spent all day making money move. It was harder than I expected.

At some point in building a marketplace, you shift from adding features to setting up the behind-the-scenes systems. This includes payment processing. This work often goes unnoticed and rarely gets shared online, but if mistakes happen, real people can lose real money.

That’s how I spent my entire week.

Adsloty is a marketplace where sponsors pay to reserve ad slots in newsletters. Writers earn money after the ads run. While this sounds simple, there is a complex system behind it that ensures every penny goes to the right place at the right time.

Here’s what I built, what went wrong, and what I learned.

Stripe Connect: paying writers directly

The first decision was about how writers get paid. I could collect all the money myself and manually send payouts. However, that would be a nightmare to handle and a legal headache right from the start.

Instead, I chose Stripe Connect. Each writer links their own Stripe account to Adsloty. When a sponsor books an ad slot, the payment goes through our platform. Stripe automatically splits the payment: the writer's share goes to their connected account, and the platform fee stays with me.

The onboarding flow looks like this:

// Generate a Stripe Connect onboarding link for the writer
let account_link = stripe_client
    .create_account_link(
        &writer.stripe_account_id,
        &format!("{}/dashboard/settings?stripe=return", config.frontend_url),
        &format!("{}/dashboard/settings?stripe=refresh", config.frontend_url),
        "account_onboarding",
    )
    .await?;

The writer clicks a link, enters their banking details on Stripe's secure page, and then returns. I never handle their bank information. Stripe takes care of identity checks and verification. That alone makes the processing fee worth it.

However, I did not expect that onboarding would not always be quick. Sometimes, Stripe needs to verify identities, which can take hours or even days. So, I had to keep track of the onboarding status and stop writers from accepting paid bookings until their accounts are fully active.

The payment flow

When a sponsor wants to book an ad slot, here's what happens:

The sponsor fills in the ad details and selects a date.
The frontend creates a checkout session through the backend.
The backend calculates the platform fee and sets up a Stripe Checkout Session.
The sponsor pays on Stripe's hosted checkout page.
Stripe sends a message to confirm the payment.
The backend creates the booking and adds a pending payout record.
After the publication date, the payout goes to the writer.

// Creating the checkout session with the platform fee split
let platform_fee = calculate_platform_fee(slot_price);

let session = stripe_client
    .create_checkout_session(CheckoutParams {
        amount: slot_price,
        currency: "usd",
        application_fee_amount: platform_fee,
        transfer_data_destination: writer.stripe_account_id,
        metadata: BookingMetadata {
            booking_id,
            writer_id,
            sponsor_id,
            newsletter_date,
        },
        success_url: format!("{}/bookings/{}?status=success", frontend_url, booking_id),
        cancel_url: format!("{}/bookings/{}?status=cancelled", frontend_url, booking_id),
    })
    .await?;

The platform charges a 10% fee. I carefully considered this amount. If it’s too high, writers will leave. If it’s too low, the business won’t be sustainable. I believe 10% is fair for the services the platform offers, including discovery, booking management, AI analysis, and payment handling. During the beta phase, I will not charge this fee at all for the first three months to attract early users.

pub fn calculate_platform_fee(amount: Decimal) -> Decimal {
    let fee_percentage = Decimal::from_str(
        &env::var("PLATFORM_FEE_PERCENTAGE").unwrap_or_else(|_| "10.0".to_string())
    ).unwrap_or(dec!(10.0));

    (amount * fee_percentage / dec!(100)).round_dp(2)
}

I made the fee adjustable using an environment variable. I've noticed that hardcoding financial details is a common mistake in many projects. When running a promotion or changing prices, you don't want to have to redeploy.

Webhooks

Stripe does not simply tell your frontend that a payment succeeded and leave it at that. The actual confirmation comes through webhooks. Stripe sends an HTTP request to your backend with the event details. This is the accurate source of information, not the redirect URL or the frontend callback. It’s the webhook that matters.

However, webhooks can arrive late, arrive twice, or not arrive at all (and then retry). Your code needs to handle all these scenarios.

async fn handle_stripe_webhook(
    State(state): State<AppState>,
    headers: HeaderMap,
    body: Bytes,
) -> AppResult<StatusCode> {
    // Verify the webhook signature — never trust unverified webhooks
    let signature = headers
        .get("stripe-signature")
        .and_then(|v| v.to_str().ok())
        .ok_or(AppError::BadRequest("Missing stripe signature".to_string()))?;

    let event = stripe_client
        .verify_webhook_signature(&body, signature, &state.config.stripe.webhook_secret)?;

    // Check if we've already processed this event (idempotency)
    if db::webhook::event_exists(&state.db, &event.id).await? {
        return Ok(StatusCode::OK); // Already handled, just acknowledge
    }

    // Persist the event before processing
    db::webhook::create_event(&state.db, &event).await?;

    match event.event_type.as_str() {
        "checkout.session.completed" => handle_checkout_completed(&state, &event).await?,
        "charge.refunded" => handle_refund(&state, &event).await?,
        "charge.dispute.created" => handle_dispute(&state, &event).await?,
        _ => {} // Ignore events we don't care about
    }

    Ok(StatusCode::OK)
}

Here are a few important points to keep in mind:

First, verify signatures. Every webhook from Stripe is signed. If you skip this step, anyone could send fake "payment succeeded" messages to your endpoint and get free products. In a marketplace that handles money, this check is essential.

Second, handle events only once. I store every webhook event ID in the database before processing it. If Stripe sends the same event again, I check the ID, see it's already been handled, and return a 200 response without doing anything. This prevents issues like processing the same payment twice or creating duplicate bookings.

Third, save the original event before I process it. If my processing fails partway through, I still have the event saved. I can replay it, debug it, or solve any issues manually. When money is involved, it’s crucial to have a clear record.

The payout lifecycle

This is where it gets interesting. A payout isn't just about sending money to the writer. It has a process that involves several stages.

pending → processing → completed
                    → failed

When a sponsor makes a payment, we create a payout record that has a status of "pending." This record stays in that state until the ad's publication date arrives. After that date, a background job processes it.

// Background job: process pending payouts for completed bookings
pub async fn process_pending_payouts(state: &AppState) -> AppResult<()> {
    let pending = db::payout::find_pending_payouts_for_completed_bookings(
        &state.db
    ).await?;

    for payout in pending {
        match stripe_client.create_transfer(&payout).await {
            Ok(_) => {
                db::payout::mark_completed(&state.db, payout.id).await?;
            }
            Err(e) => {
                tracing::error!(payout_id = %payout.id, error = %e, "Payout transfer failed");
                db::payout::mark_failed(&state.db, payout.id).await?;
            }
        }
    }

    Ok(())
}

Why can't we pay writers right away when the sponsor pays? It’s because the ad hasn’t run yet. If the writer doesn’t publish the ad or the sponsor asks for a refund before the date, we need to cancel the payout. Once we send the money, getting it back can be very difficult.

Edge cases

The happy path is straightforward: the sponsor pays, the ad runs, and the writer gets paid. But then reality hits:

Sometimes, sponsors change their minds before the ad is published. When that happens, I need to refund the entire amount, cancel the pending payment, and update the booking status. I must do all of this in one transaction so everything stays consistent.

"charge.refunded" => {
    // Cancel the payout if it hasn't been sent yet
    let cancelled = db::payout::cancel_payout_if_pending(
        &mut tx, booking_id
    ).await?;

    // Update booking status
    db::booking::mark_refunded(&mut tx, booking_id).await?;

    tx.commit().await?;
}

Failed Transfers. Sometimes, Stripe cannot send money to a writer's account. This might happen if their bank rejects the transfer or if there are issues with their Stripe account. When this occurs, the payout is marked as failed. I must inform the writer so they can update their account details and try again.

Disputes. A sponsor's bank may start a chargeback. This is the worst-case scenario. The money gets taken back, and I need to handle it carefully. This involves updating the booking, notifying both parties, and possibly flagging the account.

Each of these situations requires its own solution, state updates, and notifications. It may not be exciting work, but if we skip any steps, someone will eventually lose money and trust.

What I learned this week

Payments in a marketplace are not just a feature; they are the foundation of the system. You can't simply add them in later—they impact everything. This includes the booking flow, the notification system, the user dashboard, the admin tools, error handling, and background jobs. Everything is connected.

If I could give myself one piece of advice, it would be to start with the payment flow first. Design the booking process around how money moves, not the other way around. I followed a similar path, but I had to go back and make changes because I had incorrect assumptions about how payments work.

Additionally, read Stripe's documentation thoroughly. Don’t just skim the quickstart guide. Pay attention to the webhook best practices, the Connect account lifecycle, and the dispute handling guide. It may be dense, but every page will save you a lot of time later when you need to debug issues.

What's next

The booking process is where a sponsor selects a newsletter, picks a date, writes their advertisement, and makes a payment. This is also where our AI fit scoring comes in, analyzing the advertisement in relation to the newsletter's audience before the writer sees it.

This is what makes Adsloty unique. Payments are the base, but the booking experience is the core product.

More soon

Building in public #2: The auth rabbit hole

Jude Miracle — Sat, 21 Feb 2026 08:00:00 +0000

I spent a week on authentication. It nearly broke me.

Last time, I explained what Adsloty is and why I'm creating it. This time, I want to talk about something less exciting: authentication.

I knew handling authentication wouldn't be easy. This isn't just a simple blog or a to-do app. Adsloty deals with real money. Sponsors pay for ad slots, and writers receive payments. When money flows through your platform, the phrase "it works on my machine" isn’t enough. You must consider what happens when someone tries to break in.

I learned this lesson the hard way. Here’s what went wrong and how I fixed it.

The brute force problem

My first login setup was very basic. It included an endpoint that accepts an email and password, checks if they match, and returns a token. There were no limits or tracking, which meant someone could easily try many password guesses without any barriers.

To fix this, I made some changes to the system. I added a counter in the database to track failed login attempts. Each incorrect password increases this counter. After five failed attempts, the account locks for 30 minutes. If the user logs in successfully, the counter resets.

I also ensured users could easily regain access. If they reset their password, the account unlocks right away. Locking users out of their accounts without a way to recover is a sure way to lose them.

// after a failed login attempt
let locked = db::user::record_login_failure(&state.db, user.id).await?;

if user.is_locked() {
    return Err(AppError::ForbiddenWithReason(
        "Account locked. Please wait 30 minutes or reset your password to unlock.".to_string(),
    ));
}

// on successful login, reset the counter
db::user::record_login_success(&state.db, user.id, None).await?;

This solution isn’t complicated and doesn’t include advanced features like machine learning to find suspicious activity. However, it works, and I could implement it in a day. I can always add more sophisticated features later.

Token theft and the rotation fix

This one scared me more.

I originally used refresh tokens that lasted for 30 days. When you logged in, you would receive a short-lived access token and a long-lived refresh token. You used the refresh token to get new access tokens when the old ones expired. This is standard practice.

The problem was that if someone stole the refresh token—through a hacked device or a leaked log, for example—they could have access for 30 days without you knowing.

The solution was token rotation. Now, every time someone uses a refresh token, it gets canceled right away, and a new one is issued. The old token becomes invalid as soon as it is exchanged. So, if an attacker steals a token and tries to use it after the real user has already used it, it will fail. The time an attacker can use a stolen token shrinks from 30 days down to the time it takes the real user to make their next request.

// find the existing refresh token
let token_hash = TokenGenerator::hash_token(&refresh_token_plain);
let token = db::token::find_refresh_token(&state.db, &token_hash)
    .await?
    .ok_or(AppError::Unauthorized)?;

// revoke it immediately — it's now dead
db::token::revoke_refresh_token(&state.db, &token_hash, Some("Used for refresh")).await?;

// issue a brand new one
let (new_refresh_token_plain, expires_at) = TokenGenerator::generate_refresh_token();
let new_refresh_token_hash = TokenGenerator::hash_token(&new_refresh_token_plain);

db::token::create_refresh_token(
    &state.db,
    user.id,
    &new_refresh_token_hash,
    expires_at,
    None,
    None,
)
.await?;

Three steps. Use it, kill it, replace it. If an attacker replays the old token, step one fails because step two already ran.

It made the token process more complex, with more database updates and more possible issues to handle. But for a platform that deals with payments, it’s essential.

The cookie bug that only existed in production

This situation was frustrating because everything worked well on my local machine.

I store authentication tokens in HttpOnly cookies. For production, these cookies must have the Secure flag so they are only sent over HTTPS. That makes sense. However, I didn't realize at first that a cookie marked Secure won't be set on localhost when using plain HTTP.

After I deployed and tested the login, it just didn’t work. There were no errors. The server set the cookie, but the browser ignored it silently. I spent too much time looking at the network tabs before I figured out what was wrong.

The solution was to adjust the cookie settings based on the environment. In production, I use Secure, HttpOnly, and SameSite=Lax. In development, I use the same settings but without the Secure flag. It took only a few lines of code to fix, but it took hours to find the problem. It was the kind of bug that makes you doubt your career choices.

fn create_auth_cookies(
    access_token: &str,
    refresh_token: &str,
    user_role: &str,
    is_production: bool,
) -> HeaderMap {
    let secure_flag = if is_production { "; Secure" } else { "" };
    let same_site = "; SameSite=Lax";
    let http_only = "; HttpOnly";

    let access_cookie = format!(
        "accessToken={}; Max-Age=3600{}{}{}",
        access_token, http_only, secure_flag, same_site
    );

    // ...
}

And then where it's called:

let is_production = state.config.env == Environment::Production;
let headers = create_auth_cookies(&access_token, &refresh_token, "writer", is_production);

One boolean. That's all it took. But finding out I needed it cost me an afternoon.

Two users, two completely different flows

Adsloty has two types of users: writers and sponsors. They use the same login form, but the process is very different for each.

Writers need to provide details about their newsletter, like its name, URL, and subscriber count. They must also complete an onboarding process before they can list ad slots. Sponsors only need to give their company name to get started.

At first, I tried to use a single registration endpoint with an if statement to handle both types. This approach became messy within an hour. There were different validation rules, different database tables, and different onboarding steps. Trying to put everything into one handler made the code hard to read.

So, I separated the registration into two endpoints, one for writers and one for sponsors. I created different profile tables in the database. The JWT includes the user's role, and every protected route checks if the user is logged in and allowed to access that area. A sponsor cannot enter the writer’s dashboard, and a writer cannot access campaign management.

// router — clean separation, no branching
pub fn auth_public_router() -> Router<AppState> {
    Router::new()
        .route("/register/writer", post(register_writer))
        .route("/register/sponsor", post(register_sponsor))
        .route("/login", post(login))
        // ...
}

And the JWT generation that carries the role:

let role_str = match user.role {
    UserRole::Writer => "writer",
    UserRole::Sponsor => "sponsor",
    UserRole::Admin => "admin",
};

let access_token = jwt_service.generate_access_token(user.id, &user.email, role_str)?;

This method requires more code, but it keeps each path clear and easy to understand. If something goes wrong in the writer registration process, I know exactly where to find the issue.

Logging everything

One decision I made early on that I'm thankful for is logging every authentication event. This includes each successful login, every failed attempt, every token refresh, every email verification, and every password reset. All this information goes into an auth_events table, which includes timestamps, user IDs, IP addresses, and whether each event succeeded or failed.

db::token::log_auth_event(
    &state.db,
    AuthEventParams {
        user_id: Some(user.id),
        event_type: "login_failed",
        ip_address: None,
        user_agent: None,
        success: false,
        failure_reason: Some("Invalid credentials"),
    },
)
.await?;

Every auth function ends with one of these. It's repetitive to write, but when someone emails you saying, 'I can't log in,' you'll be glad you have it.

I haven't needed this data for a real incident yet. But when you're handling other people's money, saying "I don't know what happened" is not acceptable. When something goes wrong, and it always does, I want to know exactly what happened and when.

What I'd tell someone building auth for a payments app

Don't underestimate this task. It's not something you can do in a weekend. Every shortcut you take will likely cause problems when real money is involved.

Lock accounts after failed login attempts. Rotate your tokens regularly. Make your cookie configuration aware of the environment from the start. Keep user types separate instead of complicating things with conditionals. Also, log more information than you think you need.

None of this is new or exciting. But making sure you do it correctly, in the right order, and without any gaps is where you will spend your time.

Next time, I’ll probably write about integrating Stripe Connect and the challenges of managing webhooks in a two-sided marketplace. That has been its own adventure.

Until then.

Building in Public: Adsloty, a Newsletter Ad Marketplace

Jude Miracle — Thu, 19 Feb 2026 11:00:00 +0000

I'm building Adsloty. Here's why.

If you run a newsletter, you've probably dealt with this: a brand reaches out wanting to sponsor an issue. Cool. Then starts the back-and-forth. Pricing negotiations over email. Figuring out dates. Chasing invoices. Copy-pasting ad copy into your template manually. It works, but barely.

And if you're on the other side (sponsor), a brand trying to get in front of a newsletter audience, it's just as painful. You're DMing creators, waiting days for replies, comparing pricing across spreadsheets, and hoping the audience actually fits your product.

I kept seeing this friction and thought: there has to be a better way.

So I started building Adsloty.

What it is

Adsloty is a self-service marketplace where newsletter writers list their ad slots and sponsors book them directly. No emails back and forth. No awkward pricing conversations. Writers set their price, sponsors browse and book, and the platform handles payments and payouts.

Think of it like Calendly meets Gumroad, but specifically for newsletter ads.

The part I'm most excited about: when a sponsor submits an ad, it gets analyzed by AI before the writer even sees it. It scores how well the ad fits the newsletter's audience, checks the tone, rates the clarity of the copy, and gives the writer an estimated click range. So instead of guessing whether an ad is a good fit, you get actual data to help you decide.

Why I'm building it

Honestly? Because I wanted it to exist.

The newsletter space is booming. More people are starting newsletters, more brands want to reach those audiences, but the infrastructure to connect them is still mostly manual. The tools that exist are either too enterprise (built for massive publishers) or too scrappy (a Typeform and a Stripe link).

I wanted something in the middle. Something a solo newsletter creator could set up in minutes, embed on their site, and start earning from — without hiring a sales team or building a media kit.

And I wanted to build it myself. Not because I have to, but because I genuinely enjoy solving this kind of problem end to end.

The tech stack

This is the part some of you are here for, so let me break it down.

The backend is Rust, running on Axum. I know, I know Rust for a web app might seem like overkill, probably. But I'm learning a lot, and the performance headroom means I won't need to rewrite anything when traffic picks up. But I've grown to love writing Rust. The type system catches so many bugs before they even make it to runtime. SQLx gives me compile-time checked SQL queries against Postgres, which means if my query doesn't match the schema, it won't even compile. That alone has saved me hours of debugging.

The frontend is Next.js with the App Router, React 19, and Tailwind CSS. State management is Zustand for global state and TanStack Query for server state. Forms are handled with React Hook Form and Zod for validation. Nothing groundbreaking here, I picked tools that let me move fast without fighting the framework.

For payments, it's Stripe all the way. Checkout Sessions for sponsors, Connect for paying out writers. The platform takes a 10% fee on each booking, which is how the business sustains itself. During beta, that fee is waived for the first three months.

The AI scoring uses Google's Gemini API. When a sponsor submits an ad, the backend sends the ad copy along with the newsletter's audience data to Gemini and gets back a structured analysis: fit score, tone, clarity, estimated clicks, and recommendations. It's not meant to replace the writer's judgment — it's meant to give them a head start.

For everything else: Cloudinary for image hosting, Sentry for error tracking on both frontend and backend, Argon2 for password hashing, JWT with refresh token rotation for auth, and Governor for rate limiting.

The database is Postgres. Nothing fancy. Just well-structured tables, proper indexes, and views for the dashboard queries.

I will use this project to improve my skills in DevOps by deploying and managing it with Kubernetes. This involves:

Containerizing services with Docker and- Deploying both backend and frontend in a Kubernetes cluster
Managing settings with ConfigMaps and Secrets
Setting up Services and Ingress
Managing scaling and rolling updates
Ensuring observability and health checks

The aim is to treat this as a production system, not just an application.

I'm going to keep building in public. I'll share what's working, what's breaking, what decisions I'm making, and why. Not the curated everything is going great version. The real version.

If you're running a newsletter and want to try it out when it launches, or if you're a brand looking for a better way to sponsor newsletters, I'd love to hear from you.

More soon.

CSS Preprocessors: LESS and SASS

Jude Miracle — Sun, 30 Jan 2022 18:21:07 +0000

CSS is used to style content on a web page written in HTML, giving it a very nice look and it determines where content is displayed on the site. It also helps your website attract potential customers to your site.

But sometimes, using regular CSS to style larger and complex web pages can be a pain in the ass it’s error-prone; and it’s time-consuming. It causes us to move slowly and it makes it harder to maintain.

Another disadvantage of using regular CSS is that it works differently on different browsers. There might be cross-browser issues while using regular CSS. IE and Opera support CSS as different logic.

With CSS Preprocessors, it deals with compatibility issues with browsers by being compatible across different browsers. It makes the CSS structure easier to read and maintain. A CSS preprocessor is a scripting language that extends CSS and then compiles it back to regular CSS.

Goal

In this article, we will discuss two types of CSS preprocessors: LESS and SASS. we will discuss, differentiate and show the similarities between the two preprocessors.

What is LESS?

Less stands for Leaner Style Sheets. LESS is a dynamic preprocessor style sheet language that can be used on different browsers and can be compiled into Cascading Style Sheets (CSS) and run on the client-side or server-side. It is an open-source project and it was previously written in Ruby but now it's been replaced with JavaScript which makes it run on the client-side and complies with data very fast.

What is SASS?

SASS stands for Syntactically Awesome Style Sheet. SASS is a preprocessor scripting language that is interpreted or compiled into Cascading Style Sheets (CSS). It is the superset of CSS and it is based on Ruby.
My friend Isaac stated SASS as

SASS is short for Syntactically Awesome Style Sheet. I know, I know, syntactically sounds like a lot no? Well, what it means is that the lines( syntax ) of SASS code are so awesome that it is known as CSS with superpowers. 😀

SASS consists of two syntaxes:

Original SASS syntax (indented syntax) - It uses indentation to separate code blocks.

button
    display: inline-flex
    background-color: #111
    color: #fff
    padding: 1em 2em
    border: none
    border-radius: 25px

The file extension is .sass

SCSS (sassy CSS) - It has the formatting of CSS, it uses braces to denote code blocks. The file extension is .scss

Similarities and Differences between LESS and SASS

Both LESS and SASS have similar features but what differs is the way they are written.

Variables

Both CSS preprocessors allow the use of variables in your stylesheet. Variables are one of the most commonly used items in any programming language. LESS and SASS allows the user to define a value once and reuse it throughout the entire stylesheet. Therefore, keep your code consistent and from repetition.

SASS declares variable with a dollar symbol ($)

$ff:  "Lato", sans-serif;
$p-color: #111;

// it can be applied anywhere in our stylesheet
body {
  font-family: $ff;
  color: $p-color;
}

LESS declare a variable with @ symbol

@ff:  "Lato", sans-serif;
@p-color: #111;

// it can be applied anywhere in our stylesheet
#header {
  font-family: $ff;
  color: $p-color;
}

Mathematical operator

They both provide support for some arithmetical operations. +, -, /,* can be used to operate on any number, color or variable. This saves a lot of time when you are using variables and you feel like working on simple mathematics.

SASS

$fontSize: 8px;
body {
   font-size: $fontSize * 2;
}

$big-screen: 1016px;
$small-screen: $big-screen / 2;

LESS

@fontSize: 8px;
body {
   font-size: @fontSize * 2;
}

@big-screen: 1016px;
@small-screen: @big-screen / 2;

Mixins

They support the use of Mixins. Mixins are used to create styles that can be used and reused anywhere in your stylesheet without recreating non-semantic classes.

In SASS a @mixin directive is used to define the mixin and @include is used to include mixin in a document.

.button {
  box-shadow: 0px 0px 3px 0 rgba(0,0,0,0.3)
  border-radius: 30px;
  transistion: transition: all 0.5s ease-in-out;
}

// to include mixin in any part of our stylsheet:
.cta {
  color: #111;
  @button;
}

LESS make use of . symbols both in defining and including them in our stylesheet and brackets at the end, just like how you call a function in javascript:

.button {
  box-shadow: 15px 5px 3px 0 rgba(0,0,0,0.3)
  border-radius: 30px;
  transistion: transition: all 0.5s ease-in-out;
}

.cta {
  color: #111;
  .button();
}

Mixins can also take arguments to enhance their utility, this is called PARAMETRIC MIXINS.

Examples of parametric mixins in SASS:

@mixin round-borders ($radius) {
  border-radius: $radius;
  -moz-border-radius: $radius;
  -webkit-border-radius: $radius;
}

// And here’s how we can mix it into various rulesets:
.box {
  @include $round-borders(5px);
}

.button {
  @include $round-borders(30px);
}

LESS:

.round-borders (@radius) {
  border-radius: @radius;
  -moz-border-radius: @radius;
  -webkit-border-radius: @radius;
}

// And here’s how we can mix it into various rulesets:
.box {
  .round-borders(5px);
}

.button {
  .round-borders(30px);
}

Parametric mixins can also have default values for their parameters:

 @mixin round-borders ($radius: 5px) {
  border-radius: $radius;
  -moz-border-radius: $radius;
  -webkit-border-radius: $radius;
}

A mixin can also be used in another mixin, and it can also be used to return values. Mixins can store different values or parameters and call that function using @return.

Nesting

Nesting is the enclosure of one block of code inside another. It helps your code to be concise and it imitates the structure of your HTML. It also prevents us from rewriting selectors multiple times and makes your code easier to read and maintain.

header {
  color: black;
  nav {
    font-size: 12px;
  }
  .logo {
    width: 300px;
  }
}

It is also possible to use pseudo-selectors with your mixins using this method.

.circle {
   width: 500px;
  height: 500px;
  position: relative;

  &:after {
    content: " ";
    position: absolute;
    top: 0;
    left: 0;
    height: 200px;
    widht: 200px;
    background: yellow;
  }
}

NOTE: you can import predefine CSS preprocessor classes into other classes

Wrapping Up

In this article, we introduced and talked about two CSS preprocessors: LESS and SASS, their similarities and differences, and why you should start using it instead of regular CSS. They offer so much more, they allow you to use functions and conditional statements. Learn more about SASS and LESS .****

How to use Page Queries and Static Queries in Gatsby Application Using GraphQL

Jude Miracle — Sat, 29 Jan 2022 21:35:48 +0000

Gatsby is known for building blazing fast websites and apps by leveraging a combination of front-end technologies such as ReactJS, Webpack and GraphQL. It is also known for its massive ecosystem of plugins that use different kinds of plugins to pull data from different data sources into Gatsby. Once it gets the desired data, it uses GraphQL to query that data.

Gatsby is not just a static site generator that builds static websites (coding individual HTML pages and getting those pages ready to serve users ahead of time) but also a progressive app generator, where you can leverage all the static functionality and still be able to query the dynamic data (renders differently based on any number of changing data inputs, such as the user's location, time of day, or user actions.).

There are two parts to any web app

Static
Dynamic

Today, we will focus on the static part of a web app.

Static Data

Just as the name may be, it means data that is fixed. A fixed data set/data that remains the same after it's collected or websites that contain stable contents that are displayed using web pages. Examples like a product detail page. You don’t change product images or product attributes every few minutes.

In Gatsby, we can query this type of data with two types of queries. Static Query and Page Query. When building our website and apps with Gatsby, we sometimes don’t know when to use Page Query and Static Query. In this article, we will know the difference between Page Query and Static Query and when to use them.

Before we get started, let us know the meaning of the query.

Query in programming means a question or request that is made by a user or another computer or device. For example, Google Search, the text you enter is known as query and each word is known as a keyword. In the Database a query is a field used to locate information within a database or another location.

Note: The action of performing a query can be referred to as querying. When looking something up in a database, you're querying the database.

Static Query

Static Query is used to query data inside a component. In Gatsby, they are not dependent on an external value to fetch the data. We can use them anywhere, including on the pages. Examples like layouts and navbar. Gatsby handles Static GraphQL queries in two varieties. Static queries using the component, and static queries using the useStaticQuery hook.

Using Static Query Component

Gatsby v2 introduces the Static Query component , a new API that allows components to retrieve data via a GraphQL query.

import { graphql, Link, useStaticQuery } from 'gatsby';
import React from 'react';

export default function Navbar() {
  return (
    <StaticQuery
      query={graphql`
        query {
          site {
            siteMetadata {
              title
            }
          }
        }
      `}
      render={data => (
        <nav>
            <Link to='/'>{data.site.siteMetadata.title}</Link>
            <div className="links">
              <Link to="/">Home</Link>
              <Link to="/about">About</Link>
              <Link to="/projects">Projects</Link>
            </div>
        </nav>
      )}
    />
  )
}

Using Static Query Hook

useStaticQuery is a hook that takes a GraphQL query and returns your data. That's it, no more Render Props necessary to use a Static Query It simplifies the use of a static query component and makes it cleaner, brief and straight to the point.

import { graphql, Link, useStaticQuery } from 'gatsby';
import React from 'react';

export default function Navbar() {
  const data = useStaticQuery(graphql`
    {
      site{
        siteMetadata{
          title
        }
      }
    }
  `);
  const { title } = data.site.siteMetadata;
  return (
    <nav>
        <Link to="/">{title}</Link>
        <div className="links">
          <Link to="/">Home</Link>
          <Link to="/about">About</Link>
          <Link to="/projects">Projects</Link>
        </div>
    </nav>
  );
}

Notice a few things here:

We're using another tagged template literal to pass on our query.
We no longer need the name of the query (it was just MyQuery).
We've added the constant for the data above the return of our JSX.
We're using the data inside of our JSX to get the title (data.site.siteMetadata.title).

Another thing about using static query hooks is that you can create your own custom hooks that use useStaticQuery in them. For example, you need to query the site title several times in your app. Instead of a call to useStaticQuery in each component, you can extract it out to a custom hook. You can learn how to create custom hooks in Gatsby

Page Query

Gatsby’s graphql tag enables page components to query data via a GraphQL query. If we want to query data for specific pages we generally opt for Page Query. For example, our About page will use a page query. Generally, we use Page Queries to dynamically generate templates/pages. For example, think of the project detail pages where you display all the details about your project on your portfolio website, if you have so many projects it means so many pages. We can do this by using createPages hook in your gatsby-node.js file. All we need is a path and a unique identifier for each Project.

const path = require('path');

exports.createPages = async ({ graphql, actions }) => {

    const { data } = await graphql(`
        query Projects {
            allMarkdownRemark(sort: {fields: frontmatter___date, order: DESC}) {
                nodes {
                    frontmatter {
                        slug
                    }
                }
            }
        }
    `);

    data.allMarkdownRemark.nodes.forEach(node => {
        actions.createPage({
            path: '/projects/' + node.frontmatter.slug,
            component: path.resolve('./src/templates/project-details.js'),
            context: { slug: node.frontmatter.slug }
        });
    });
};

Take a look at the above code. All we are doing is fetching a unique ID(slug) related to each project and its path alias for each project from a data source which in our case is a slug and that is the slug of that particular project. Then we are passing this data to our template file as a context value. We can access this value at /src/templates/ProjectDetail.js. Now in our ProjectDetail component, we can use the unique ID(slug) to query data for each project. Take a look at the code below.

import React from 'react';
import Layout from '../components/Layout';
import Img from 'gatsby-image';
import * as styles from '../styles/project-details.module.css';
import { graphql } from 'gatsby';

export default function ProjectDetails({ data }) {
    const { stack, title, featuredImg} = data.markdownRemark.frontmatter
    return (
        <Layout>
            <div className={styles.details}>
                <h2>{title}</h2>
                <h3>{stack}</h3>
                <div className={styles.featured}>
                    <Img fluid={featuredImg.childImageSharp.fluid} />
                </div>
            </div>
        </Layout>
    )
}
export const query = graphql`
query ProjectsDetails($slug: String) {
    markdownRemark(frontmatter: {slug: {eq: $slug}}) {
      frontmatter {
        stack
        title
        featuredImg {
          childImageSharp {
            fluid {
              ...GatsbyImageSharpFluid
            }
          }
        }
      }
    }
  }

We are using the slug variable to get a specific markdown file and then once we have that we are getting all the data from it and then we can access all of this data inside this projectDetails components. Gatsby uses the variable value at build time to generate the Project details for each project. To learn more about page queries, visit this link.

Difference between Page Query and Static Query

Page queries can accept variables (via pageContext) but can only be added to page components.
Static Query does not accept variables. This is because static queries are used inside specific components and can appear lower in the component tree including pages.
Depending on the use case, if we want to query data for specific pages we generally opt for Page Query whereas Static Query is used to query data inside a component.
A single component that's used throughout the application will use a static query, whereas a dynamic page like our About page will use a page query.

Wrapping Up

Hope you now have a nice overview of how, when and where to use queries in your gatsby applications.

If you would like to chat or have any questions, drop them in the comments I’m always happy to talk.

Thanks for reading and happy coding!

Recipe layout | Codepen-challenge

Jude Miracle — Tue, 15 Jun 2021 00:33:22 +0000

https://codepen.io/JudeIV/pen/abJPdBW