DEV Community: mcw999

How I stopped manually posting to 6 platforms and built an automated PR pipeline for my side projects

mcw999 — Sun, 01 Mar 2026 23:55:18 +0000

When you're a solo developer with a day job, actually building the project is maybe 60% of the work. The other 40%—the part nobody talks about—is getting anyone to notice it exists. And honestly, that 40% is where most of us fall apart.

My usual pattern: ship something, post about it once on Twitter, maybe write a Qiita article if I'm feeling ambitious, get distracted by the next thing, and watch the project quietly die with 12 GitHub stars.

The problem isn't motivation. It's friction. Writing a technical article for Qiita, reformatting it for Dev.to, condensing it to 280 characters for Twitter, crafting a Reddit post that doesn't get immediately downvoted—each platform has different norms, different formats, different audiences. Doing all of that manually for every project update is genuinely exhausting, and when it competes with actually writing code, it loses every time.

So last year I started building tooling to automate this. Along the way I hit a bunch of interesting technical problems. This article is about those problems and how I solved them—the pipeline architecture, the AI integration patterns, and some gotchas that cost me several evenings.

The Core Problem: Multi-Platform Content Distribution

The fundamental challenge is that each platform wants something different from the same underlying information:

Twitter: 280 chars, casual tone, hashtags
Dev.to: Markdown, technical depth, frontmatter metadata
Qiita: Japanese-preferred, structured technical content
Reddit: Community-appropriate framing, no obvious self-promotion

If you're maintaining all of these by hand, you're essentially doing N times the work for one project update.

The approach I landed on: use AI to transform a single structured project description into platform-appropriate content, then automate the distribution through GitHub Actions workflows triggered from my desktop.

Step 1: Automated Project Analysis

Before you can generate content, you need structured data about your project. I built a scanner that reads project files—package.json, Cargo.toml, pubspec.yaml, go.mod, pyproject.toml—and infers the tech stack.

The dependency-to-tech-stack mapping approach worked better than I expected. Here's a simplified version of the npm pattern:

const NPM_STACK_MAP: Record<string, string> = {
  react: "React",
  next: "Next.js",
  vue: "Vue",
  svelte: "Svelte",
  "@tailwindcss/vite": "TailwindCSS",
  tailwindcss: "TailwindCSS",
  express: "Express",
  prisma: "Prisma",
  "drizzle-orm": "Drizzle ORM",
  three: "Three.js",
  electron: "Electron",
  trpc: "tRPC",
};

function inferStackFromPackageJson(deps: Record<string, string>): string[] {
  const detected = new Set<string>();
  for (const [dep] of Object.entries(deps)) {
    for (const [key, label] of Object.entries(NPM_STACK_MAP)) {
      if (dep === key || dep.includes(key)) {
        detected.add(label);
      }
    }
  }
  return Array.from(detected);
}

I built similar mappings for Flutter's pubspec.yaml (16 patterns covering riverpod, bloc, firebase, supabase, etc.) and Go modules.

One thing that tripped me up: category keyword ordering matters. I was classifying projects into 11 categories (crypto, saas, tool, finance, game, education, health, social, mobile-app, platform, other) using keyword matching, and "budget wallet" was getting classified as saas because finance wasn't being checked before looser matches. The fix was simple—order the category checks by specificity—but it took an embarrassingly long time to diagnose.

For deeper analysis, I integrated Claude CLI using the --print mode flag:

claude --print --permission-mode bypassPermissions \
  "Analyze this project and return JSON with fields: name, category, targetAudience, techStack, tagline"

The --print flag was a complete game changer. My original approach used PowerShell's SendKeys + AppActivate to automate a visible terminal window—send keystrokes, wait fixed sleep durations, scrape output. It worked maybe 70% of the time. The other 30% it would hang indefinitely because the timing was off, usually when the machine was under load.

Switching to --print mode with stdout capture made the whole thing reliable and scriptable. No windows, no timing hacks, just a subprocess you can await. Analysis takes 30–120 seconds depending on project complexity, versus under 0.5 seconds for the file-based scan. Both have their place.

I also introduced a .pr-meta.json file that projects can include at their root:

{
  "name": "MyProject",
  "nameJa": "マイプロジェクト",
  "tagline": "A tool that does X",
  "taglineJa": "Xをするツール",
  "category": "tool",
  "targetAudience": ["developers", "devops"],
  "techStack": ["Rust", "React", "Tauri"],
  "description": "Longer description here..."
}

When this file exists, the scanner returns complete data in under 0.5 seconds. This is particularly important for multilingual fields—there's no way to infer Japanese copy from source files, so you need a metadata file for that.

Step 2: Git as a Shared Data Store

The architecture decision I'm most happy with: using a GitHub repository as the shared data store between my desktop app and GitHub Actions workflows.

Here's the pattern:

my-hub-repo/
  content/
    projects/
      my-project.json      # Project definition + metadata
      another-project.json
    meta/
      posting-history.json # What was posted, when, where
      traffic-history.json # Accumulated analytics data
  .github/
    workflows/
      post-content.yml     # The actual posting automation

The desktop app reads and writes JSON files in this repo. GitHub Actions workflows also read from the same files to know what to post and where. Both sides stay in sync because Git is the source of truth.

This means I can trigger a workflow from my desktop using gh workflow run post-content.yml --field project=my-project, and the workflow reads content/projects/my-project.json to get everything it needs.

One problem with this approach: concurrent modifications. When I fetch fresh analytics data, I'm pulling from the remote while potentially having local uncommitted changes. The ordering matters here:

git stash
git pull --ff-only origin main
git stash pop  # NOT git stash drop

I originally had stash drop instead of stash pop. That meant every analytics refresh silently discarded any local work in progress. Not a fun bug to debug when you realize your edits are just... gone.

Step 3: Accumulating Analytics Past the 14-Day Limit

The GitHub Traffic API only returns the last 14 days of data. If you're polling infrequently, you'll have gaps. If you want to track trends over months, you need to accumulate data yourself.

My approach: on every analytics fetch, merge new data into an existing traffic-history.json file, keying by date string to deduplicate:

function mergeTrafficData(
  existing: TrafficEntry[],
  incoming: TrafficEntry[]
): TrafficEntry[] {
  const byDate = new Map<string, TrafficEntry>();

  // Load existing data first
  for (const entry of existing) {
    byDate.set(entry.date, entry);
  }

  // Incoming data overwrites (it's fresher)
  for (const entry of incoming) {
    byDate.set(entry.date, entry);
  }

  return Array.from(byDate.values()).sort(
    (a, b) => new Date(a.date).getTime() - new Date(b.date).getTime()
  );
}

This runs on every refresh and commits the updated file to the repo. Cheap, reliable, and you maintain a complete historical record without any external database.

Step 4: Platform API Authentication

Each platform has a different auth pattern, and you have to handle them individually. There's no shortcut here.

async function checkQiitaConnection(token: string): Promise<string> {
  const resp = await fetch("https://qiita.com/api/v2/authenticated_user", {
    headers: { Authorization: `Bearer ${token}` },
  });
  if (!resp.ok) throw new Error("Invalid token");
  const user = await resp.json();
  return user.id; // Returns username
}

async function checkDevToConnection(token: string): Promise<string> {
  const resp = await fetch("https://dev.to/api/users/me", {
    headers: { "api-key": token }, // Different header name!
  });
  if (!resp.ok) throw new Error("Invalid token");
  const user = await resp.json();
  return user.username;
}

Qiita uses Authorization: Bearer, Dev.to uses api-key as a header. Small difference, but it'll bite you if you try to generalize.

Zenn and Reddit are worth calling out as special cases. Zenn has no public API, so connection checking is impossible—you can only post manually. Reddit's OAuth flow is complex enough that I ended up recommending manual posting there too. Being honest about platform limitations in your UI prevents user frustration.

For storing tokens, I use Tauri's plugin-store. The tokens sit in a local config file, which is convenient but means they're effectively plaintext on disk. To use them safely in GitHub Actions, I sync them as GitHub secrets:

gh secret set QIITA_API_TOKEN --body "$token"
gh secret set DEVTO_API_KEY --body "$token"

This way the Actions workflows can access them securely, and you only have to set them once from your desktop.

Tauri-Specific Patterns Worth Knowing

If you're building anything with Tauri v2, a couple of things made my life significantly easier.

Type-safe IPC with generics: Tauri's invoke<T>() supports generic type parameters, which means you can get proper TypeScript types from your Rust commands:

const projects = await invoke<Project[]>("get_all_projects");
const result = await invoke<ScanResult>("scan_project", { path: projectPath });

Memoize your API hook: I centralized all IPC calls in a useApi() hook. The problem is that React recreates the hook object on every render by default, which causes unnecessary re-renders in child components. The fix:

const api = useMemo(() => createApi(), []);

Easy fix, but easy to miss. Without it, you get cascading re-renders that are annoying to trace.

Windows + Unicode paths: If your app runs on Windows and users might have Japanese or other non-ASCII characters in their directory paths, you'll hit encoding issues when spawning subprocesses. The workaround is converting to 8.3 short paths using PowerShell's Scripting.FileSystemObject before passing them to CLI tools. Not elegant, but it works.

What I Actually Built

I ended up wrapping all of this into a Tauri desktop app I call PR Dashboard—a 10-screen app that handles project scanning, content generation via Claude, multi-platform posting through GitHub Actions workflows, and analytics visualization using Recharts. The whole thing uses my GitHub repo as its data store.

Was it worth building? For me, yes—I'm posting consistently now instead of in random bursts. But honestly, most of what I described above can be implemented in a much simpler form: a few shell scripts, a cron job, and some GitHub Actions workflows. You don't need a desktop app to get the core benefit.

The patterns that matter regardless of what you build:

Use Claude CLI's --print mode for non-interactive AI integration
Accumulate data that APIs only return in rolling windows
Let Git be your shared data store between local tools and CI/CD
Handle platform-specific auth individually, not generically
Be explicit in your UI about what you can't automate

I wrote a more detailed guide on my blog covering the GitHub Actions workflow setup and the content generation prompts in more depth: https://mcw999.github.io/mcw999-hub/blog/pr-dashboard-guide/

If you're a solo developer who's shipped things that quietly disappeared because you didn't have time to promote them, this is a solvable problem. The tooling doesn't have to be fancy—it just has to reduce the friction enough that you actually do it.

Building Location-Based AR Content Discovery with PostGIS and Three.js

mcw999 — Wed, 25 Feb 2026 11:37:42 +0000

When I started building a location-based AR platform, the part I thought would be easy turned out to be the hardest: efficiently querying which AR objects are "near" a user in real time, then rendering them correctly in 3D space relative to the camera. GPS coordinates feel simple until you're trying to do spatial radius queries on thousands of user-placed objects and then translate those coordinates into a Three.js scene that doesn't drift or jitter as the user moves.

This post is about that problem. If you're building anything with geo-anchored content — AR apps, location games, place-based social features — you've probably run into the same wall.

The Core Problem: Bridging GPS Space and 3D Render Space

GPS gives you latitude and longitude (and sometimes altitude). Three.js works in a local coordinate system measured in meters (or whatever unit you define). These two worlds don't talk to each other naturally.

The naive approach is to just subtract coordinates:

// DON'T do this
const dx = targetLon - userLon;
const dy = targetLat - userLat;
object.position.set(dx, 0, dy);

This breaks down immediately because one degree of longitude near the equator is about 111km, but near the poles it's nearly zero. Your scene will look fine if you're testing in one place, then completely fall apart for users somewhere else — or even for the same user moving north.

The correct approach is to convert from WGS84 (GPS coordinates) to a local East-North-Up (ENU) coordinate system centered on the user's current position. This gives you actual metric distances in a flat plane.

// Convert lat/lon to ENU coordinates relative to an origin point
function gpsToENU(targetLat, targetLon, originLat, originLon) {
  const R = 6371000; // Earth radius in meters
  const dLat = (targetLat - originLat) * (Math.PI / 180);
  const dLon = (targetLon - originLon) * (Math.PI / 180);

  const avgLat = ((targetLat + originLat) / 2) * (Math.PI / 180);

  // East (X) and North (Z) in meters
  const east = R * dLon * Math.cos(avgLat);
  const north = R * dLat;

  // In Three.js, Z is depth (into screen), so we negate north for alignment
  return { x: east, y: 0, z: -north };
}

// Usage
const userPos = { lat: 35.6812, lon: 139.7671 }; // Tokyo example
const anchorPos = { lat: 35.6815, lon: 139.7680 };

const enuCoords = gpsToENU(
  anchorPos.lat, anchorPos.lon,
  userPos.lat, userPos.lon
);

arObject.position.set(enuCoords.x, enuCoords.y, enuCoords.z);

The key insight: you recalculate this every time the user moves. The origin is always the user's current position, so objects near them are close to (0,0,0) in scene space and objects far away are simply further from origin. This keeps your floating point numbers small and precise, which matters a lot for AR stability.

The Database Side: Spatial Queries with PostGIS

Before you can render anything, you need to know which AR objects exist near the user. This is where a lot of people reach for a simple "find all objects and filter client-side" approach. Works fine at 100 objects. Terrible at 50,000.

PostGIS on top of Postgres (which Supabase uses) gives you proper spatial indexing. Here's the table setup:

-- Enable PostGIS extension (already enabled in Supabase)
create extension if not exists postgis;

-- AR content anchors table
create table ar_anchors (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users(id),
  title text not null,
  content_type text check (content_type in ('3d_model', 'text', 'photo')),
  content_url text,
  metadata jsonb default '{}',
  location geography(Point, 4326) not null,
  created_at timestamptz default now()
);

-- Spatial index — critical for performance
create index ar_anchors_location_idx 
  on ar_anchors using gist(location);

-- Query: find anchors within 500 meters of user
-- You'd call this via a Supabase RPC or directly
select 
  id,
  title,
  content_type,
  content_url,
  metadata,
  ST_Y(location::geometry) as lat,
  ST_X(location::geometry) as lon,
  ST_Distance(
    location, 
    ST_MakePoint(139.7671, 35.6812)::geography
  ) as distance_meters
from ar_anchors
where ST_DWithin(
  location,
  ST_MakePoint(139.7671, 35.6812)::geography,
  500  -- radius in meters
)
order by distance_meters asc;

ST_DWithin with a geography type gives you geodesic distance calculations that are accurate regardless of where on earth you are. It also uses your spatial index, so this query stays fast even with a lot of data.

In Supabase you'd expose this as an RPC function and call it from your client whenever the user's position changes significantly (I use a 10-meter threshold to avoid spamming queries on every GPS tick).

Handling the Camera Orientation Problem

Here's where things get tricky for actual AR. You need to align your Three.js camera with the physical direction the device is facing. The DeviceOrientationEvent gives you alpha (compass heading), beta (tilt), and gamma (roll). Mapping these to a Three.js camera rotation without gimbal lock or drift is genuinely annoying.

A few things I learned the hard way:

Don't use Euler angles directly. The order matters and you'll spend hours debugging rotation weirdness. Use quaternions.

Alpha isn't always compass-relative. On iOS, alpha is relative to the initial orientation when the page loaded. On Android with Chrome, it's relative to magnetic north. You need to handle both cases, ideally by requesting requestPermission on iOS and checking absolute on the DeviceOrientationEvent.

The drift problem is real. Magnetometers in phones are noisy. Any metal nearby (a car, a building with rebar) will throw off your compass. You can apply a low-pass filter to smooth jitter, but there's no perfect solution — this is a hardware limitation.

// Simplified camera orientation from device sensors
function updateCameraOrientation(event, camera) {
  // event.alpha = heading (degrees, 0-360)
  // event.beta = tilt front/back (-180 to 180)
  // event.gamma = tilt left/right (-90 to 90)

  if (event.alpha === null) return;

  const alphaRad = (event.alpha * Math.PI) / 180;
  const betaRad = (event.beta * Math.PI) / 180;
  const gammaRad = (event.gamma * Math.PI) / 180;

  // Build rotation quaternion — ZXY order matches device orientation spec
  const euler = new THREE.Euler(betaRad, alphaRad, -gammaRad, 'ZXY');
  const quaternion = new THREE.Quaternion().setFromEuler(euler);

  // Apply a correction for screen orientation if needed
  const screenOrientation = window.screen.orientation?.angle ?? 0;
  const screenQuat = new THREE.Quaternion().setFromAxisAngle(
    new THREE.Vector3(0, 0, 1),
    (-screenOrientation * Math.PI) / 180
  );

  camera.quaternion.copy(quaternion.multiply(screenQuat));
}

// Attach listener
window.addEventListener('deviceorientation', (e) => {
  updateCameraOrientation(e, myThreeCamera);
}, true);

Even with this, you'll notice the camera "drifts" slightly over time on many devices. Some teams add a manual calibration step where users point their phone at a QR code or a known landmark to reset the heading. For social AR where exact precision isn't critical, a slight drift is often acceptable — users are forgiving if a virtual object is a few degrees off from where it "should" be.

PWA vs Native: What Actually Matters Here

If you're doing this as a PWA (which I am with CityCanvas), you face one specific limitation: DeviceOrientationEvent requires either HTTPS or a permission prompt on iOS 13+. Make absolutely sure your deployment is HTTPS, otherwise you'll get zero sensor data and no useful error message.

Capacitor (which wraps your web app as a native app) gives you access to native AR frameworks if you need them — ARKit on iOS, ARCore on Android. These handle a lot of the sensor fusion for you and give much better tracking. But they also add significant complexity to your build pipeline. For a first version, I'd suggest getting the web-based approach working first, then considering Capacitor/native AR as an enhancement.

The PWA approach also lets you test quickly in a browser on desktop using a webcam and keyboard controls simulating GPS movement, which is way faster than deploying to a phone every time.

What I'd Do Differently

Looking back at the architecture decisions:

Start with a smaller search radius than you think you need. 500 meters sounds reasonable but if users are placing lots of content, that's potentially hundreds of objects in a city center. I now paginate the results and only fully load models for objects within 100 meters, showing simpler "beacon" markers for anything 100-500m away.

Think about content loading budget from day one. Fetching a 3D model for every anchor in range will destroy load times. You need LOD (level of detail) — simple sprites far away, full 3D models close up. Three.js has a LOD class for this.

GPS accuracy is wildly variable. In dense urban environments (tall buildings, the "urban canyon" effect), GPS can be off by 20-50 meters. Design your UX so a 20m placement error isn't catastrophic. Making objects bigger, or giving users a visual "search" interaction rather than just walking to an exact spot, both help.

Don't try to solve all the hard AR problems at once. Surface tracking, occlusion, persistent anchors across sessions — these are research-level problems. Ship something that's fun with imperfect GPS and orientation, then iterate.

The geo + 3D rendering combination is genuinely one of the more interesting technical areas right now, and there's a lot of room to build things that weren't possible a few years ago just using browser APIs and cheap cloud databases. Most of the hard stuff is solvable with the approaches above — the magic is in what you let users create and discover with it.

I wrote a more detailed guide on my blog covering the full architecture including the 3D model generation pipeline and Capacitor setup: https://mcw999.github.io/mcw999-hub/blog/city-canvas-guide/

Building an offline-first budget tracker in Flutter that actually works without internet

mcw999 — Mon, 23 Feb 2026 14:21:21 +0000

Second line empty

So I've been working on a personal budget tracker app for the past several months, and the single biggest pain point I kept running into wasn't UI design or state management — it was this: the app was useless whenever my phone had spotty connectivity.

I commute by subway. Signal drops constantly. I'd try to log an expense right after buying coffee and the app would just... spin. Or worse, silently fail and I'd forget to record it later. Every commercial budgeting app I tried had the same problem — they're cloud-first, and when the cloud isn't available, neither is your data.

If you're building a Flutter finance app (or any data-entry mobile app, really), this problem is worth solving properly. Here's what I learned.

Why offline-first matters more than you think

There's a difference between "works offline" and "offline-first". Most apps grudgingly tolerate offline mode — they'll cache some reads but refuse to write anything until the network comes back. Offline-first means your app is designed assuming the network is unreliable, and syncing is a background concern, not a gating requirement.

For a budget tracker specifically, this matters because:

Expenses happen at the point of purchase, which is often in a store basement, on a train, or somewhere with terrible signal
The longer the gap between spending and logging, the more you forget (or rationalize away)
Financial data is sensitive — you don't necessarily want it dependent on a third-party server being up

The core challenge is: how do you persist data locally, keep your UI reactive, and optionally sync when connectivity returns — all without making your codebase a nightmare?

Local persistence: picking your storage layer

In Flutter, you've got a few realistic options for structured local data:

SQLite via sqflite — the most flexible, good for complex queries, but you're writing raw SQL and managing schema migrations yourself.

drift (formerly Moor) — type-safe SQLite wrapper with code generation. Great for anything relational. More boilerplate upfront but worth it.

Hive — NoSQL key-value store, very fast, zero native dependencies (works on all platforms including web). Great for simpler data shapes.

Isar — newer, fast, has a query language, works well with Flutter's reactive patterns.

For a budget tracker where the core entities are transactions and categories (and maybe budgets per period), I ended up using drift because I needed real queries — things like "sum of expenses by category this month" — that would've been painful with a pure key-value store.

Here's a simplified version of the schema:

// database/tables.dart
import 'package:drift/drift.dart';

class Transactions extends Table {
  IntColumn get id => integer().autoIncrement()();
  TextColumn get title => text().withLength(min: 1, max: 100)();
  RealColumn get amount => real()();
  TextColumn get categoryId => text()();
  IntColumn get type => intEnum<TransactionType>()(); // income or expense
  DateTimeColumn get date => dateTime()();
  BoolColumn get isSynced => boolean().withDefault(const Constant(false))();
}

class Categories extends Table {
  TextColumn get id => text()();;
  TextColumn get name => text()();
  TextColumn get icon => text()();
  TextColumn get colorHex => text()();

  @override
  Set<Column> get primaryKey => {id};
}

The isSynced column is key — it lets you track which records need to be pushed to a backend when connectivity returns, without blocking the user from entering data.

Making the UI reactive to local data

One thing that took me longer than it should have to internalize: with drift, your queries return Streams, not Futures. This means your UI automatically rebuilds when data changes. You don't need to manually refresh anything.

// In your repository
Stream<List<TransactionEntry>> watchTransactionsForMonth(DateTime month) {
  final start = DateTime(month.year, month.month, 1);
  final end = DateTime(month.year, month.month + 1, 0, 23, 59, 59);

  return (select(transactions)
        ..where((t) => t.date.isBetweenValues(start, end))
        ..orderBy([(t) => OrderingTerm.desc(t.date)]))
      .watch();
}

// And a derived query for the summary
Stream<double> watchMonthlyTotal(DateTime month, TransactionType type) {
  final start = DateTime(month.year, month.month, 1);
  final end = DateTime(month.year, month.month + 1, 0, 23, 59, 59);

  final query = selectOnly(transactions)
    ..addColumns([transactions.amount.sum()])
    ..where(transactions.date.isBetweenValues(start, end))
    ..where(transactions.type.equals(type.index));

  return query.map((row) => row.read(transactions.amount.sum()) ?? 0.0).watchSingle();
}

In your widget, you pair this with a StreamBuilder (or use riverpod with StreamProvider, which is what I do in practice because it handles loading/error states more cleanly).

The result: you enter a transaction, it writes to local SQLite, the stream emits, the summary widget rebuilds. Zero network involved. Feels instant because it is instant.

The "how much do I have left today" problem

The specific UX goal I had was: open the app, immediately see how much budget you have left for the day. Not this month, not this week — today. Because that's the decision you're making when you're standing at a register.

This means you need to calculate:

daily_remaining = (monthly_budget / days_in_month) - expenses_today

But that naive formula breaks down. What if you spent way over budget last week? Should that affect today's display? I found it more useful to show:

daily_remaining = (monthly_budget - total_expenses_so_far) / days_remaining_in_month

This "rolling daily budget" approach is more motivating — it tells you what you can actually spend for the rest of the month given where you are now, rather than pretending each day is independent.

I keep this calculation in a simple domain service, not in the UI layer. Makes it easy to test.

Handling sync when you do have connectivity

If you want to sync to a backend (I use a simple Supabase project), the pattern I settled on is:

All writes go to local SQLite first, with isSynced = false
A background sync service watches network connectivity using connectivity_plus
When the network comes back, it queries for all records where isSynced = false and pushes them
On success, it marks them as synced

The key design decision: never block the user on sync. The app doesn't wait for confirmation from the server. If the sync fails, the record stays marked as unsynced and the service will retry next time.

You do need to think about conflict resolution if the same app runs on multiple devices, but for a single-user personal finance app, "last write wins" is usually acceptable. Just make sure your records have a updatedAt timestamp so the server can sort it out.

State management: keeping it sane

I use riverpod because it plays well with streams from drift and handles async state cleanly. But the pattern that matters more than the specific library is keeping your layers clean:

Database layer: raw drift queries, returns streams/futures
Repository layer: wraps the database, exposes domain-friendly methods
Provider layer: exposes streams to the UI, handles transformations
UI layer: just reads state and dispatches events, no business logic

When I broke this and put "just a small calculation" in a widget, I always regretted it during testing.

A few things that bit me

Date handling: Store dates as UTC in the database. Display in local time. Sounds obvious, but if you forget, you'll get off-by-one errors at midnight that are incredibly confusing to debug.

Schema migrations: drift has a migration system, use it. Don't just delete and recreate the database during development — you'll train yourself into bad habits, and then when real users have the app, you'll have no idea how to migrate their data.

Large amount inputs: Mobile keyboards are painful for entering amounts. A custom numeric keypad widget that feels like a calculator is worth the effort. Users entering 1234 is better UX than 1,234.00 in a text field.

Testing the offline state: Use connectivity_plus's mock in tests, and actually test what happens when sync fails. It's easy to only test the happy path and discover the offline behavior is broken right when you demo it to someone.

What I actually shipped

I put all of this together into 家計簿アプリ (Budget Tracker) — an offline-first Flutter app focused specifically on the "what can I spend today" use case. The whole point is that it works on the subway, at the store, wherever. You open it, you know your number, you log what you spend.

The architecture described above is pretty much exactly what's running in production. Local SQLite via drift, reactive streams for the UI, optional Supabase sync in the background.

If you're starting from scratch

My honest recommendation for building something similar:

Start with drift even if you think your data model is simple. You'll add queries you didn't anticipate.
Design for offline from day one. Retrofitting offline support onto a cloud-first architecture is genuinely painful.
Get the "quick entry" flow perfect before anything else. In a budget app, if logging a transaction takes more than 3 taps, people stop doing it.
The "daily remaining" number is more actionable than monthly totals for most people — worth thinking about what the primary metric of your app actually is.

The offline-first constraint sounds like a limitation but it actually simplifies a lot of things. When you're not waiting on network requests, your UX becomes more predictable, your tests become simpler, and your users stop getting random loading spinners.

I wrote a more detailed guide on my blog covering the drift setup, the sync architecture, and the daily budget calculation logic in full: https://mcw999.github.io/mcw999-hub/blog/budget-tracker-guide/

Cryptocurrency Market Overheating and Cooling Detection System Built with Node.js + TypeScript

mcw999 — Sun, 22 Feb 2026 23:57:52 +0000

Cryptocurrency Market Overheating and Cooling Detection System Built with Node.js + TypeScript

In cryptocurrency trading, accurately identifying market overheating and cooling timing is extremely important. This article explains how to build a price, volume, and open interest data analysis system using the KuCoin Futures API to detect market signals in real-time.

System Overview

This system analyzes three key data points of the cryptocurrency market:

Price Data: Market trends and price volatility
Volume Data: Trading activity levels
Open Interest Data: Position accumulation status

From this data, we detect four types of signals and classify market overheating/cooling states into four levels.

Tech Stack

{
  "dependencies": {
    "express": "^4.18.2",
    "typescript": "^5.0.0",
    "node-fetch": "^3.3.0",
    "@types/node": "^18.0.0"
  },
  "devDependencies": {
    "vitest": "^0.34.0",
    "@types/express": "^4.17.17"
  }
}

Project Structure

src/
├── types/
│   ├── market.ts
│   └── signals.ts
├── services/
│   ├── kucoinApi.ts
│   ├── signalDetector.ts
│   └── coolingAnalyzer.ts
├── utils/
│   └── timeframe.ts
├── routes/
│   └── analysis.ts
└── app.ts

Type Definition Design

First, let's define types for market data and signals:

// types/market.ts
export interface MarketData {
  timestamp: number;
  price: number;
  volume: number;
  openInterest: number;
  symbol: string;
}

export type TimeFrame = 'HTF' | 'LTF';
export type HTFInterval = '4h' | '1d';
export type LTFInterval = '15m' | '1h';

// types/signals.ts
export type SignalType = 'HIGH_ZONE' | 'PRICE_WEAK' | 'VOLUME_WEAK' | 'OI_SIGNAL';
export type CoolingLevel = 'confirmed' | 'watch' | 'mild' | 'none';

export interface DetectedSignal {
  type: SignalType;
  strength: number;
  timestamp: number;
  timeframe: TimeFrame;
}

export interface CoolingAnalysis {
  level: CoolingLevel;
  signals: DetectedSignal[];
  confidence: number;
  recommendation: string;
}

KuCoin API Connection Service

Let's implement a service to fetch data from the KuCoin Futures API:

// services/kucoinApi.ts
import fetch from 'node-fetch';

export class KuCoinApiService {
  private readonly baseUrl = 'https://api-futures.kucoin.com';

  async getKlineData(
    symbol: string, 
    interval: string, 
    limit: number = 100
  ): Promise<MarketData[]> {
    try {
      const endpoint = `/api/v1/kline/query`;
      const params = new URLSearchParams({
        symbol,
        granularity: this.convertInterval(interval),
        from: (Date.now() - limit * this.getIntervalMs(interval)).toString(),
        to: Date.now().toString()
      });

      const response = await fetch(`${this.baseUrl}${endpoint}?${params}`);
      const data = await response.json();

      return this.parseKlineData(data.data, symbol);
    } catch (error) {
      console.error('KuCoin API Error:', error);
      throw new Error('Failed to fetch market data');
    }
  }

  async getOpenInterest(symbol: string): Promise<number> {
    const endpoint = `/api/v1/contracts/${symbol}`;
    const response = await fetch(`${this.baseUrl}${endpoint}`);
    const data = await response.json();

    return parseFloat(data.data.openInterest);
  }

  private convertInterval(interval: string): string {
    const mapping: { [key: string]: string } = {
      '15m': '900',
      '1h': '3600',
      '4h': '14400',
      '1d': '86400'
    };
    return mapping[interval] || '3600';
  }

  private getIntervalMs(interval: string): number {
    const mapping: { [key: string]: number } = {
      '15m': 15 * 60 * 1000,
      '1h': 60 * 60 * 1000,
      '4h': 4 * 60 * 60 * 1000,
      '1d': 24 * 60 * 60 * 1000
    };
    return mapping[interval] || 60 * 60 * 1000;
  }

  private parseKlineData(rawData: any[], symbol: string): MarketData[] {
    return rawData.map(item => ({
      timestamp: parseInt(item[0]),
      price: parseFloat(item[2]), // close price
      volume: parseFloat(item[5]),
      openInterest: 0, // fetched separately
      symbol
    }));
  }
}

Signal Detection Logic

Let's implement a service that detects four types of signals:

// services/signalDetector.ts
export class SignalDetector {

  detectHighZone(data: MarketData[]): DetectedSignal | null {
    if (data.length < 20) return null;

    const recent = data.slice(-5);
    const historical = data.slice(-20, -5);

    const recentHigh = Math.max(...recent.map(d => d.price));
    const historicalAvg = historical.reduce((sum, d) => sum + d.price, 0) / historical.length;

    const priceRatio = recentHigh / historicalAvg;

    if (priceRatio > 1.15) { // 15% or more increase
      return {
        type: 'HIGH_ZONE',
        strength: Math.min((priceRatio - 1) * 100, 100),
        timestamp: Date.now(),
        timeframe: 'HTF'
      };
    }

    return null;
  }

  detectPriceWeak(data: MarketData[]): DetectedSignal | null {
    if (data.length < 10) return null;

    const recent = data.slice(-3);
    const comparison = data.slice(-10, -3);

    // Detect declining price momentum
    const recentSlope = this.calculateSlope(recent.map(d => d.price));
    const comparisonSlope = this.calculateSlope(comparison.map(d => d.price));

    if (recentSlope < comparisonSlope * 0.5 && comparisonSlope > 0) {
      return {
        type: 'PRICE_WEAK',
        strength: Math.abs(recentSlope - comparisonSlope) * 10,
        timestamp: Date.now(),
        timeframe: 'LTF'
      };
    }

    return null;
  }

  detectVolumeWeak(data: MarketData[]): DetectedSignal | null {
    if (data.length < 10) return null;

    const recentVolume = data.slice(-3).reduce((sum, d) => sum + d.volume, 0) / 3;
    const avgVolume = data.slice(-10).reduce((sum, d) => sum + d.volume, 0) / 10;

    const volumeRatio = recentVolume / avgVolume;

    if (volumeRatio < 0.7) { // 30% or more volume decrease
      return {
        type: 'VOLUME_WEAK',
        strength: (1 - volumeRatio) * 100,
        timestamp: Date.now(),
        timeframe: 'LTF'
      };
    }

    return null;
  }

  detectOISignal(data: MarketData[], currentOI: number): DetectedSignal | null {
    if (data.length < 5) return null;

    const recentPriceChange = (data[data.length - 1].price - data[data.length - 5].price) / data[data.length - 5].price;
    const avgOI = data.reduce((sum, d) => sum + d.openInterest, 0) / data.length;

    // Decreasing OI during price rise is an overheating signal
    if (recentPriceChange > 0.05 && currentOI < avgOI * 0.9) {
      return {
        type: 'OI_SIGNAL',
        strength: Math.abs(recentPriceChange) * 100,
        timestamp: Date.now(),
        timeframe: 'HTF'
      };
    }

    return null;
  }

  private calculateSlope(values: number[]): number {
    const n = values.length;
    const xSum = (n * (n - 1)) / 2;
    const ySum = values.reduce((sum, val) => sum + val, 0);
    const xySum = values.reduce((sum, val, i) => sum + i * val, 0);
    const xSquareSum = (n * (n - 1) * (2 * n - 1)) / 6;

    return (n * xySum - xSum * ySum) / (n * xSquareSum - xSum * xSum);
  }
}

Cooling Level Analysis

Integrate multiple signals to determine the cooling level:

// services/coolingAnalyzer.ts
export class CoolingAnalyzer {

  analyzeCoolingLevel(signals: DetectedSignal[]): CoolingAnalysis {
    const signalWeights = {
      HIGH_ZONE: 0.4,
      PRICE_WEAK: 0.2,
      VOLUME_WEAK: 0.2,
      OI_SIGNAL: 0.2
    };

    let totalScore = 0;
    let weightSum = 0;

    signals.forEach(signal => {
      const weight = signalWeights[signal.type];
      totalScore += signal.strength * weight;
      weightSum += weight;
    });

    const confidence = weightSum > 0 ? totalScore / (weightSum * 100) : 0;
    const level = this.determineCoolingLevel(confidence, signals);

    return {
      level,
      signals,
      confidence,
      recommendation: this.generateRecommendation(level, confidence)
    };
  }

  private determineCoolingLevel(confidence: number, signals: DetectedSignal[]): CoolingLevel {
    const highZoneSignal = signals.find(s => s.type === 'HIGH_ZONE');
    const weaknessSignals = signals.filter(s => 
      s.type === 'PRICE_WEAK' || s.type === 'VOLUME_WEAK' || s.type === 'OI_SIGNAL'
    );

    if (highZoneSignal && weaknessSignals.length >= 2 && confidence > 0.7) {
      return 'confirmed';
    } else if (highZoneSignal && weaknessSignals.length >= 1 && confidence > 0.5) {
      return 'watch';
    } else if (weaknessSignals.length >= 1 && confidence > 0.3) {
      return 'mild';
    }

    return 'none';
  }

  private generateRecommendation(level: CoolingLevel, confidence: number): string {
    const recommendations = {
      confirmed: 'Market overheating confirmed. Consider reducing positions.',
      watch: 'Signs of overheating detected. Monitor closely and prepare for profit-taking.',
      mild: 'Mild bearish signals detected. Watch for trend changes.',
      none: 'No clear overheating signals currently detected.'
    };

    return recommendations[level];
  }
}

Express API Endpoints

Implement API endpoints to provide analysis results:

// routes/analysis.ts
import { Router } from 'express';
import { KuCoinApiService } from '../services/kucoinApi';
import { SignalDetector } from '../services/signalDetector';
import { CoolingAnalyzer } from '../services/coolingAnalyzer';

const router = Router();
const apiService = new KuCoinApiService();
const signalDetector = new SignalDetector();
const coolingAnalyzer = new CoolingAnalyzer();

router.get('/analyze/:symbol', async (req, res) => {
  try {
    const { symbol } = req.params;
    const { timeframe = 'HTF', interval = '4h' } = req.query;

    // Fetch data
    const marketData = await apiService.getKlineData(symbol, interval as string);
    const currentOI = await apiService.getOpenInterest(symbol);

    // Integrate open interest data
    marketData.forEach(data => data.openInterest = currentOI);

    // Detect signals
    const signals = [
      signalDetector.detectHighZone(marketData),
      signalDetector.detectPriceWeak(marketData),
      signalDetector.detectVolumeWeak(marketData),
      signalDetector.detectOISignal(marketData, currentOI)
    ].filter(signal => signal !== null);

    // Analyze cooling level
    const analysis = coolingAnalyzer.analyzeCoolingLevel(signals);

    res.json({
      symbol,
      timeframe,
      analysis,
      timestamp: Date.now()
    });

  } catch (error) {
    console.error('Analysis error:', error);
    res.status(500).json({ error: 'Analysis failed' });
  }
});

export default router;

Test Implementation

Unit testing with Vitest is also important:

// tests/signalDetector.test.ts
import { describe, it, expect } from 'vitest';
import { SignalDetector } from '../src/services/signalDetector';
import type { MarketData } from '../src/types/market';

describe('SignalDetector', () => {
  const detector = new SignalDetector();

  it('should detect high zone signal', () => {
    const mockData: MarketData[] = Array.from({ length: 20 }, (_, i) => ({
      timestamp: Date.now() - (20 - i) * 60000,
      price: i < 15 ? 100 : 120, // Last 5 candles show 20% increase
      volume: 1000,
      openInterest: 5000,
      symbol: 'BTCUSDT'
    }));

    const signal = detector.detectHighZone(mockData);

    expect(signal).toBeTruthy();
    expect(signal?.type).toBe('HIGH_ZONE');
    expect(signal?.strength).toBeGreaterThan(15);
  });

  it('should detect volume weakness', () => {
    const mockData: MarketData[] = Array.from({ length: 10 }, (_, i) => ({
      timestamp: Date.now() - (10 - i) * 60000,
      price: 100,
      volume: i < 7 ? 1000 : 500, // Last 3 candles show 50% volume drop
      openInterest: 5000,
      symbol: 'BTCUSDT'
    }));

    const signal = detector.detectVolumeWeak(mockData);

    expect(signal).toBeTruthy();
    expect(signal?.type).toBe('VOLUME_WEAK');
  });
});

This system provides a comprehensive framework for detecting cryptocurrency market overheating and cooling