DEV Community: Kuba Brzeziński

I built a Solana memecoin trading bot with Claude AI - here's what actually happened

Kuba Brzeziński — Sun, 07 Jun 2026 08:18:04 +0000

About a month ago I got tired of manually watching crypto charts. Trading felt like a full-time job - stressful, emotional, and impossible to scale. So I did what any developer would do: I decided to automate it.

But I didn't want to actually trade. I wanted to understand the market first. So I built a monitoring bot - one that watches new token launches on Pump.fun, runs them through Claude AI for scam detection, and tracks what would have happened if I'd bought.

No real money on the line. Just data.

The idea

The idea was simple in theory:

Listen for new tokens on Pump.fun via WebSocket
Pre-filter obvious scams (creator holds > 50%, liquidity < $5k, under 30 seconds old)
Send survivors to Claude Haiku with token metadata
Claude decides: buy or skip, with a confidence score
Track price via Helius WebSocket, simulate TP/SL

TypeScript, Node.js, Solana web3.js, Jupiter API, and Claude Haiku as the brain.

What actually went wrong

Problem 1: Pump.fun kept changing their API.
This was the most frustrating part. I'd get the WebSocket working, leave it running overnight, come back to zero data. Their endpoint structure changed multiple times during the week I was building. No changelog, no warning. Just silence.

Problem 2: WebSocket reconnection logic was a mess.
My initial implementation didn't handle disconnects gracefully. When Helius dropped the connection (which happened often on the free tier), the bot just... stopped. Silently. I added reconnection logic but it took longer than it should have.

Problem 3: TP/SL never triggered.
The price monitoring was working, but my sell logic had a race condition. By the time the condition was evaluated, the price had already moved past the threshold. Classic async bug - and in memecoin time, a few hundred milliseconds is the difference between profit and loss.

Problem 4: Latency killed the concept.
This is what ultimately paused the project. Helius free tier adds meaningful latency. By the time my bot detected a new token, parsed it, called Claude, got a response, and checked the price - early buyers had already moved the price. The monitoring data was accurate. The timing wasn't.

What Claude actually did well

The AI layer was honestly the most reliable part. I fed Claude token metadata - holder distribution, liquidity, creator wallet history, description - and asked for a buy/skip decision with confidence score.

It caught patterns I hadn't thought to hardcode: celebrity name tokens with no context, descriptions that were copy-pasted from other coins, supply distributions that looked clean on the surface but had obvious accumulation patterns.

False positives happened, but the pre-filters kept Claude API costs low - roughly $15/month at 500 calls a day.

The results

Honest answer: mostly simulated losses, with occasional gems.

The bot found a few tokens early that pumped 200-300% within an hour. But for every one of those, there were fifteen that went to zero within minutes. The AI filtering helped - it avoided the most obvious scams - but it couldn't predict community momentum, influencer shills, or pure luck.

What I finished up

The core monitoring logic works. What I cleaned up for this challenge:

Fixed the README (including a typo in the repo description)
Added proper reconnection handling with exponential backoff
Documented the known latency limitation so anyone who forks this doesn't spend three days figuring out why free-tier RPC kills the strategy

What I learned

Infrastructure constraints matter as much as the logic. You can have a perfect algorithm and lose because your data arrives 400ms late.

Claude Haiku is surprisingly good at pattern recognition on structured data - better than I expected for the cost.

And Pump.fun's API instability is a real moat. The teams profiting from memecoin trading aren't just smarter - they have paid, reliable infrastructure.

Would I build it again? Yes. Would I run it with real money on Helius free tier? Absolutely not.

Repo: https://github.com/KubaBrzezinskiDev/trading-monitor-bot

Maven vs Gradle

Kuba Brzeziński — Fri, 05 Jun 2026 11:37:27 +0000

How to actually choose and stop overthinking it

Every Java project starts with the same question nobody wants to spend time on: Maven or Gradle?

And yet somehow people spend hours on it. So let me just tell you how to think about it, what the real differences are, and when each one makes sense.

A bit of history so you understand why both exist

Ant came first. If you have never seen an Ant build file, consider yourself lucky. Pure XML, zero conventions, you had to manually describe every single step of the build. Want to compile? Write a task. Want to copy files? Write a task. Want to run tests? You already know. It worked, but maintaining it was a part-time job. Nobody starts new projects on Ant in 2025. If you encounter it, you are maintaining legacy code and you have my condolences.

Maven came along and said: what if we just agreed on how projects should be structured, and the build tool handled the rest automatically? Revolutionary idea at the time. You declare what you want, Maven figures out how to do it. pom.xml tells Maven what your project is, what it depends on, and what plugins you need. The rest is convention.

Gradle came later and said: what if we kept the good parts of Maven but replaced XML with an actual programming language? And also made it faster?

That is basically the whole history.

Bazel also exists, built by Google for building Google-scale monorepos. Genuinely impressive engineering. Also genuinely unnecessary for anything below "we have 50 teams committing to the same repo". If someone suggests Bazel for your three-module Spring Boot app, smile and change the subject.

What Maven actually is

Maven is convention over configuration taken seriously. Your project follows a standard structure:

src/
  main/
    java/
    resources/
  test/
    java/
    resources/
pom.xml

And because Maven knows this structure, it knows how to compile, test, package, and deploy your project without you explaining any of it. The pom.xml is just a declaration of intent.

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>3.3.5</version>
    </dependency>
</dependencies>

That is it. Maven resolves transitive dependencies, downloads what it needs, puts everything in the right place.

The lifecycle is fixed and predictable: validate → compile → test → package → verify → install → deploy. You can hook into any phase with a plugin but you cannot reorder them. That is a feature, not a limitation.

The downside: XML is verbose. A moderately complex pom.xml with profiles, plugin configurations, and multi-module setup becomes long fast. It is readable, but long.

What Gradle actually is

Gradle replaces XML with a build script written in either Groovy or Kotlin DSL. The Kotlin DSL (build.gradle.kts) is the modern choice - you get type safety, autocomplete in IntelliJ, and it looks like actual code because it is actual code.

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web:3.3.5")
    testImplementation("org.springframework.boot:spring-boot-starter-test")
}

Cleaner. And because it is a real programming language, you can do things that would require painful plugin setups in Maven. Custom logic, conditional dependencies, dynamic versioning - it is all just code.

The real advantage though is performance. Gradle has two things Maven does not:

Incremental builds - Gradle tracks which tasks have inputs that changed. If you only touched one module, Gradle only rebuilds that module. Maven rebuilds everything.

Build cache - Gradle can cache task outputs and reuse them across builds, even across machines if you set up a remote cache. On a large multi-module project this is not a small difference. It can be the difference between a 2-minute build and a 15-minute build.

The downside: because Gradle is flexible, it is also possible to make a mess. A build.gradle.kts that has accumulated three years of custom logic from five different developers is genuinely hard to understand. Maven's rigidity protects you from this.

The honest comparison

	Maven	Gradle
Config format	XML	Kotlin / Groovy DSL
Learning curve	Low	Medium
Build speed	Slower on large projects	Faster (incremental + cache)
Flexibility	Low	High
Predictability	Very high	Depends on who wrote it
IDE support	Excellent	Excellent
Spring Boot support	First class	First class
Multi-module projects	Verbose but works	Cleaner and faster

How to actually choose

Pick Maven if:

You are building something where other people need to understand the build quickly. New team members, open source contributors, junior developers. Maven's pom.xml is boring in the best possible way - everyone knows where to look for what. There are no surprises.

Also pick Maven if your company already uses it everywhere. Consistency in tooling across a team is worth more than marginal build speed improvements.

Pick Gradle if:

You have a multi-module project and build time is actually bothering you. Gradle's incremental builds make a meaningful difference at scale. If you have a monorepo with 10+ modules and Maven is rebuilding all of them on every change, switching to Gradle will feel like a revelation.

Also pick Gradle if you want more expressive build scripts. Kotlin DSL is genuinely nicer to write than XML once you are past the initial setup.

Starting a new Spring Boot project from scratch?

Honestly it does not matter much. Spring Initializr generates both. Pick Gradle with Kotlin DSL if you want to learn something modern, pick Maven if you want zero friction and maximum familiarity. You can always migrate later - it is annoying but not catastrophic.

The migration question

People ask about migrating between them more than you would expect.

Maven to Gradle is more common and relatively straightforward. Gradle has an init task that can import a Maven project automatically as a starting point. It will not be perfect but it gets you 80% of the way there.

Gradle to Maven is rarer and more painful because you are losing flexibility, not gaining it. If you are considering it, you probably had a bad experience with an overly complex Gradle setup, which is a people problem more than a tooling problem.

What the Spring Boot ecosystem defaults to

Spring Initializr offers both. The official Spring documentation shows examples in both. Most tutorials online cover both.

In practice, most enterprise Spring Boot projects I have seen use Maven. Most newer, developer-led projects lean toward Gradle. Neither is wrong.

TL;DR

Ant: do not touch unless forced
Maven: boring, predictable, everyone understands it, great for teams
Gradle: faster on large projects, more expressive, easier to overcomplicate
Bazel: only if you are Google, or want to feel like Google

BookEase - booking plugin for WordPress

Kuba Brzeziński — Mon, 25 May 2026 12:18:47 +0000

I got frustrated with $89 WordPress booking plugins — so I built my own

And it actually works. Here's how.

If you've ever tried to add appointment booking to a WordPress site, you know the pain.

Bookly — $89 one-time, or $9.99/month for the full version. Half the features are locked behind add-ons that cost extra.

Simply Schedule Appointments — free version is crippled. Pro starts at $99/year.

Amelia — $79/year. Nice UI, but massive plugin that loads scripts on every page.

For a barber, a personal trainer, or a small clinic — this is just too much. They want to accept bookings online. They don't want to pay a monthly subscription forever.

So I built BookEase — a lightweight WordPress booking plugin. One shortcode. No monthly fees. Pay once.

Here's how I built it, what I learned, and what tripped me up.

The goal

I wanted to build something that:

Works with [bookease_form] on any page
Guides clients through 4 steps: Service → Date & Time → Details → Confirm
Sends email confirmations automatically
Has a clean admin panel to manage bookings
Is written properly — PHP 8.1+, PSR-4, no jQuery spaghetti

Architecture

I went with the classic WordPress plugin OOP structure:

bookease/
├── bookease.php              # Main plugin file
├── includes/
│   ├── class-bookease.php    # Core orchestrator
│   ├── class-loader.php      # Action/filter queue
│   ├── class-activator.php   # DB tables on activation
│   └── class-bookease-emails.php
├── admin/
│   ├── class-bookease-admin.php
│   └── partials/             # Dashboard, bookings, services, settings
├── public/
│   ├── class-bookease-public.php
│   ├── js/public.js
│   └── partials/booking-form.php
└── languages/
    └── bookease.pot

The class-loader.php pattern keeps hooks clean — you queue actions and filters, then run them all at once. No scattered add_action() calls everywhere.

The database

Three tables, created with dbDelta() on activation:

$sql = "CREATE TABLE {$wpdb->prefix}bookease_services (
    id bigint(20) NOT NULL AUTO_INCREMENT,
    name varchar(255) NOT NULL,
    duration int(11) NOT NULL DEFAULT 60,
    price decimal(10,2) NOT NULL DEFAULT 0.00,
    description text,
    created_at datetime DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id)
) $charset_collate;";

dbDelta() is the WordPress-safe way to create/upgrade tables. It only applies changes — so activating the plugin on an existing install won't destroy data.

The slot engine — the tricky part

This is where most booking plugins get it wrong. You can't just divide working hours by service duration.

You need to account for:

Service duration (how long the appointment takes)
Buffer time between appointments
Existing bookings (no double-booking)
Past time slots (don't show slots that already passed today)

My approach:

private function get_available_slots( $date, $service_id ) {
    $service  = $this->get_service( $service_id );
    $duration = (int) $service->duration;
    $break    = (int) get_option( 'bookease_break_between', 0 );
    $hours    = $this->get_working_hours( $date );

    if ( ! $hours['open'] ) return [];

    $slots    = [];
    $current  = strtotime( $date . ' ' . $hours['from'] );
    $end      = strtotime( $date . ' ' . $hours['to'] );
    $now      = time() + 3600; // 1h buffer for same-day bookings

    while ( $current + ( $duration * 60 ) <= $end ) {
        $slot_end = $current + ( $duration * 60 );

        if ( $current >= $now && ! $this->is_slot_taken( $current, $slot_end, $date ) ) {
            $slots[] = date( 'H:i', $current );
        }

        $current += ( ( $duration + $break ) * 60 );
    }

    return $slots;
}

The is_slot_taken() check queries the DB for any confirmed/pending booking that overlaps the proposed slot. Simple but effective.

The frontend — AJAX 4-step form

No page reloads. State lives in a JS object:

const state = {
    step: 1,
    serviceId: null,
    serviceName: null,
    date: null,
    time: null,
    customerName: null,
    customerEmail: null,
    customerPhone: null,
    notes: null
};

Each step validates before moving to the next. On step 2, picking a date fires an AJAX call to get available slots:

async function fetchAvailableSlots( date ) {
    const response = await fetch( bookease.ajax_url, {
        method: 'POST',
        headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
        body: new URLSearchParams({
            action: 'bookease_get_available_times',
            nonce:  bookease.nonce,
            date:   date,
            service_id: state.serviceId
        })
    });
    const data = await response.json();
    renderTimeSlots( data.slots );
}

Nonce verification on every AJAX handler — non-negotiable.

Email notifications

WordPress's wp_mail() is fine for most use cases. I built HTML templates with inline CSS (because email clients are a nightmare):

public function send_customer_confirmation( $booking_id ) {
    $booking = $this->get_booking( $booking_id );
    $to      = $booking->customer_email;
    $subject = sprintf( '[%s] Your Booking is Confirmed', get_option('bookease_business_name') );

    $headers = ['Content-Type: text/html; charset=UTF-8'];
    $message = $this->get_confirmation_template( $booking );

    wp_mail( $to, $subject, $message, $headers );
}

Compatible with any SMTP plugin (WP Mail SMTP, FluentSMTP) since it hooks into wp_mail.

Security checklist

Every form and AJAX handler has:

✅ wp_verify_nonce() — prevents CSRF
✅ sanitize_text_field() / sanitize_email() — cleans input
✅ $wpdb->prepare() — prevents SQL injection
✅ current_user_can() — capability checks in admin

This is table stakes for any WordPress plugin. Don't skip it.

What I'd do differently

1. Add Google Calendar sync from day one.
It's the most requested feature by anyone running a service business. I'll add it in v1.1.

2. Better error handling on the frontend.
Right now errors are generic. Should be more specific ("That slot was just taken, please pick another").

3. Consider a REST API instead of admin-ajax.
admin-ajax.php works but the WP REST API is cleaner and easier to test.

The result

A working WordPress booking plugin. 4-step form, smart availability engine, email notifications, clean admin panel. PHP 8.1+, PSR-4, ~44KB.

👉 kuba07.gumroad.com/l/bookease

Takeaways

Building a WordPress plugin from scratch taught me a lot about the ecosystem — hooks, wpdb, nonces, capability checks. It's a different world from modern frameworks, but the fundamentals (clean architecture, security, separation of concerns) are the same everywhere.

If you're a developer looking to build passive income, WordPress plugins are still a solid bet. The market is huge, the bar for quality is surprisingly low, and a well-built plugin can sell for years.

Happy to answer questions in the comments!

Tags: #wordpress #php #webdev #sideproject