DEV Community: akshay sharma

Solo founders who also run marketing hit the same wall. You write three good posts on a good week. Then launch week swallows eve

akshay sharma — Wed, 23 Sep 2026 15:30:24 +0000

Solo founders who also run marketing hit the same wall. You write three good posts on a good week. Then launch week swallows everything and distribution goes quiet while the product ships.

The usual fix is a scheduler that posts on autopilot. That kills the silence but creates a new problem: it posts without you, and sometimes it posts things you would not have approved.

We built Cadencz to avoid that tradeoff. Launches, decisions, positioning, and audience notes live in one inspectable source. The system turns that into drafts across 9 live channels. You approve every post before it goes anywhere.

The approval queue is the part that matters. Nothing reaches a live channel without your sign-off. The Writer drafts, the Critic flags weak angles, you decide. Automation only kicks in at the publishing step, after approval.

The loop runs weekly: the Planner maps the week, the Writer composes drafts, you review the queue, Cadencz schedules what you approved, and the Analyst reports what worked. That collapses seven separate decisions into one review pass, so nothing sits forgotten for two weeks while you're heads-down on launch.

Two caveats. The 9 channels are the only ones live today; anything else is planned, not available. And this is built to keep distribution steady, not to guarantee reach — the Critic keeps quality up, but what ships and when is still on you.

If a weekly planning loop sounds useful, watch the 30-sec demo. Most of it is the approval queue, which is where you'll actually spend your time.

The problem: your token dies quietly, and nobody tells the user

akshay sharma — Fri, 11 Sep 2026 04:31:07 +0000

If you integrate more than one social platform's API, you already know each provider handles tokens differently. Some expire in hours. Some refresh silently in the background. Some revoke access the moment a user changes a password, with no webhook to tell you.

None of that is the hard part. The hard part is what happens next.

Publish time is the worst possible moment to find out

Say a post is scheduled for 9am. Your job runs, calls the API, and gets a 401. The token is dead.

From the user's side, this looks identical to "the tool stopped working." They don't see an auth error. They see a missing post. By the time they notice, the slot is gone, and there's no way to get it back. You can retry a rate limit. You cannot retry a scheduled tweet from three hours ago.

So the failure isn't really a technical one. It's a timing one. You found out about a fixable problem at the one moment you could no longer fix it.

The fix: treat the connection as a first-class object

The decision that actually matters here is small: stop treating "post to platform X" as a single step, and start treating the connection itself as something with a health state.

Something like this:

Connection {
  id
  platform
  status: "healthy" | "needs_reconnect" | "revoked"
  last_checked_at
  refresh_token
}

Before a scheduled job runs, it checks the connection's status, not just whether it has a token:

function preflightCheck(connection) {
  if (connection.status === "revoked") {
    return "needs_reconnect" // user has to act
  }
  if (isExpiringSoon(connection)) {
    const refreshed = tryRefresh(connection)
    if (!refreshed) {
      connection.status = "needs_reconnect"
      return "needs_reconnect"
    }
  }
  return "healthy"
}

If the check fails, the queued post moves to a needs_reconnect state instead of just vanishing. That state is visible to the user, ideally days before the scheduled slot, not after.

Two error classes, not one

This only works if you separate two things that look the same in a stack trace but require completely different fixes:

A token that's simply stale. Your backend can refresh it programmatically, no user involved. This should never surface as an error at all.

A permission the user revoked. Nothing on your side can restore this. Only the user, going back through the provider's consent screen, can fix it.

Collapsing these into one generic "auth failed" state is the actual bug. The first case should be invisible. The second case needs a clear, specific prompt: reconnect this account, here's why, here's the link.

The transferable takeaway

Any integration that fans out to multiple platforms needs a way to surface "reconnect this account" before the deadline, not after. That means checking connection health on a schedule, separately from running the job that depends on it, and giving the user enough lead time to actually act.

We built this into Cadencz because it schedules and publishes across 11 platforms through connected accounts, and the backend owns every OAuth callback rather than the frontend, so connection state is centralized in one place instead of scattered across per-platform request code.

If you're integrating even two or three platforms, the same principle holds: a dead token is not a publish-time problem. It's a state you should already know about.

The problem: another dashboard tab nobody asked for

akshay sharma — Wed, 09 Sep 2026 03:30:44 +0000

If you already live inside Claude or Codex, you do not want a browser tab for every tool you use. You want to trigger the action from where you are already working. That is the actual demand behind MCP adoption, not novelty.

Cadencz is MCP-ready for Claude, Codex, and other MCP clients. That fact is simple to state. The design consequence is not.

When the client owns the UI, your tool names are the UI

A normal product controls its own interface. Buttons, labels, confirmation dialogs, all of it designed by you.

Expose your pipeline as MCP tools and that control disappears. The client renders whatever it wants. The model decides which tool to call based on the tool's name, description, and argument schema. Those three things are now your entire interface.

Here is roughly the shape of a tool definition:

{
  "name": "list_drafts",
  "description": "List queued social post drafts awaiting approval. Returns id, platform, and status for each draft.",
  "parameters": {
    "type": "object",
    "properties": {
      "status": {
        "type": "string",
        "enum": ["pending", "approved", "rejected"]
      }
    }
  }
}

A vague description here is not a cosmetic issue. It is a routing bug. If the description says "manage content" instead of naming the exact action and its return shape, the model has nothing precise to match against user intent. It will call the wrong tool, or the right tool with the wrong arguments, and there is no UI affordance to catch that before execution.

The constraint you cannot hide behind a nice description

Cadencz's own workflow is: learn the product, plan and draft, approve in a queue, then schedule and publish.

An MCP client can reasonably ask to draft a post. It can reasonably ask to list what is in the queue. Publishing is different. That step needs a human approval, and the tool surface has to say so explicitly, not imply it through a comment nobody reads.

Concretely, that means no single publish tool that silently sends. Instead, something like list_drafts, get_draft, and a separate request_approval or mark_approved step that a human, not the model, triggers. The boundary between "the model can do this" and "a person has to do this" has to live in which tools exist, not in a policy note.

If your schema makes an unsafe action look identical to a safe one, the model will eventually treat them the same way.

The takeaway

Write tool descriptions as if the model has no other context, because it usually does not. Name the exact action, the exact return shape, and the exact preconditions.

Return errors a model can act on. "Draft not found" with the id it searched for is useful. A generic 500 is not; the model cannot retry, correct, or explain the failure to the user.

If you are building an MCP server for your own product, this is the design review worth doing before you ship it: read every tool name and description as if you were a model with zero prior knowledge of your app. Would you call the right one?

Question for the end of the week, no product angle attached.

akshay sharma — Tue, 08 Sep 2026 12:15:23 +0000

Question for the end of the week, no product angle attached.

What's one workflow habit you changed this year that actually moved your output, not just your feeling of being productive?

I ask because most habit changes people mention are cosmetic. A new app, a new notebook, a new morning routine that lasts eleven days. Those rarely show up in the actual work.

The changes that seem to stick are smaller and less exciting. Writing drafts before checking any metrics. Batching research on one day and writing on another. Naming files by the idea inside them instead of the date. None of these sound impressive in a tweet, but they change what gets finished.

I'm curious what your version of that is, and whether you can point to something concrete that got better because of it. Not a vibe. A number, a time saved, a thing you stopped doing.

Drop it below if you've got one. Curious what other devs have landed on this year.

If you are building a feature where a user picks a time and a job fires later, you have a timezone bug waiting for you. It does

akshay sharma — Mon, 07 Sep 2026 16:45:16 +0000

If you are building a feature where a user picks a time and a job fires later, you have a timezone bug waiting for you. It does not show up in testing. It shows up twice a year, on the two nights the clocks change.

Here is the problem. A scheduled post carries two different pieces of information. One is the exact instant the job must fire. The other is the human intent behind that instant — "9am my time." Most schemas store only one of these and quietly lose the other.

𝗧𝗵𝗲 𝗻𝗮𝗶𝘃𝗲 𝘃𝗲𝗿𝘀𝗶𝗼𝗻

scheduled_posts (
  id UUID,
  content TEXT,
  fire_at TIMESTAMPTZ  -- stored as UTC
)

This looks correct. You convert the user's local pick to UTC once, at creation time, and store that. The job scheduler just checks fire_at <= now(). Clean.

It breaks the moment the user's offset changes. Say someone in New York picks 9am and you store 2026-11-01T13:00:00Z. That is correct — until November 3rd, when the US falls back and 9am Eastern is now 14:00 UTC, not 13:00. Your stored instant is stable. The user's intent is not. The post fires at what is now 8am for them, not 9am. Nothing crashed. Nothing logged an error. The time is just wrong.

𝗧𝗵𝗲 𝗳𝗶𝘅 𝗶𝘀 𝘁𝗼 𝘀𝘁𝗼𝗿𝗲 𝗯𝗼𝘁𝗵

scheduled_posts (
  id UUID,
  content TEXT,
  local_time TIME,          -- '09:00'
  local_date DATE,          -- '2026-11-01'
  timezone TEXT             -- 'America/New_York', IANA identifier
)

Now you resolve fire_at at read time, not write time, using the stored IANA identifier plus the current tz database. This preserves intent correctly across DST changes. But it introduces its own edge case: during the hour a DST transition repeats or skips, a wall-clock time is ambiguous or invalid. On November 1st in the US, 1:30am happens twice. On March 8th, 2:30am does not happen at all. If your resolution logic just calls the local time API and takes whatever it returns, you will silently pick one of two valid instants, or crash on an invalid one, depending on the library.

𝗧𝗵𝗲 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻

Keep both fields. Treat the timezone identifier as part of the permanent record, set once, at the moment the user makes the choice. Never re-derive it later from the user's current browser timezone, because a traveling user or a stale session will hand you a different value than the one they meant when they scheduled the post. The identifier is data, not a runtime lookup.

𝗪𝗵𝗮𝘁 𝘁𝗼 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝘁𝗲𝘀𝘁

Do not just test the happy path where a schedule fires on a normal Tuesday. Pick the two DST transition dates for your target region this year and write explicit test cases for the ambiguous hour (fall back) and the skipped hour (spring forward). Assert what your scheduler does with a job set to fire inside that window. Most tz libraries have a documented but non-obvious default (usually "earlier" or "later" occurrence) — know what yours picks, because your users will hit it whether you tested for it or not.

Cadencz schedules and publishes posts across live platforms, which means every queued post carries this same fire-at-instant-versus-local-intent problem underneath it.

If you're building anything with recurring jobs — cron-style schedulers, reminder systems, billing cycles — this is worth fixing before your first DST transition, not after someone reports a post that fired an hour off.

We caught an architecture mistake in our own spec before it shipped.

akshay sharma — Mon, 07 Sep 2026 10:15:14 +0000

We caught an architecture mistake in our own spec before it shipped.

The early draft of the Cadencz backend spec assumed Next.js could carry both the frontend and a chunk of the product API, using its /app/api routes as a shortcut. On paper it saves a service. In practice it quietly merges two things that should stay apart.

The correction we made: Next.js is frontend only. No product API lives inside it. A separate backend owns every OAuth callback, every billing webhook, every scheduling state change, every AI credit check.

This isn't a framework preference. It's about what each of those things actually needs.

OAuth callbacks need a stable, versioned endpoint that doesn't move when someone redesigns a page. Billing webhooks from a payment provider need a service that can retry, log, and stay up even if the frontend deploy is mid-rollout. Scheduling state changes need a source of truth that isn't tied to a request/response cycle built for rendering HTML.

Mixing these into the same codebase as your UI works fine until you need to redeploy the frontend without touching billing logic, or debug a failed webhook without wading through page components. Then the coupling shows up as an incident, not a code smell.

The tradeoff is real. Two services mean two deploy pipelines, two places to monitor, and more upfront setup than a monolith. For a weekend project, that overhead isn't worth it.

For anything that touches money or third-party auth, it is. A billing webhook failing silently because your frontend build broke is a worse outcome than the extra infrastructure it takes to prevent it.

The lesson generalizes past this one stack. Frontend and backend separation is a decision you make based on what your system touches, not a default you inherit from a tutorial. If your app never handles payments or OAuth, a combined setup might be the right call. If it does, treat the split as a requirement, not a nice-to-have.

What would you add? Where has skipping this separation actually bitten you in production?

If your onboarding flow asks for a URL and promises to learn the user's voice from it, you have a problem you probably haven't n

akshay sharma — Sun, 06 Sep 2026 11:30:34 +0000

If your onboarding flow asks for a URL and promises to learn the user's voice from it, you have a problem you probably haven't named yet: a marketing site is not a voice sample.

We hit this building the Cadencz onboarding step. Paste a website URL, and the system builds a Product Brain: what you sell, who you sell it to, and how you write. Two of those three are easy. The third one lies to you if you're not careful.

𝗪𝗵𝗮𝘁 𝗮 𝘀𝗶𝘁𝗲 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝘁𝗲𝗹𝗹𝘀 𝘆𝗼𝘂

A homepage and a pricing page are excellent sources for product facts. Scrape them and you get real answers to real questions: What does this do. Who is it for. What claims is the team willing to stand behind in public. Those are extractable, checkable, and stable over time.

𝗪𝗵𝗮𝘁 𝗮 𝘀𝗶𝘁𝗲 𝗰𝗮𝗻𝗻𝗼𝘁 𝘁𝗲𝗹𝗹 𝘆𝗼𝘂

Landing-page copy is not written by the person who will post on LinkedIn next Tuesday. It's usually written by a founder in pitch mode, a contractor, or a copywriter optimizing for conversion, not for how the founder actually talks. The sentence length on a pricing page tells you nothing about the sentence length the founder uses when they're annoyed about a bug on X. The emoji count on a features section tells you nothing about whether this person uses emoji at all in a real post.

We tried treating both as the same kind of signal early on. It didn't work. The model would infer a formal, hedge-everything tone from the homepage and apply it everywhere, including to a founder who writes like they're texting a friend.

𝗧𝗵𝗲 𝗳𝗶𝘅: 𝘀𝗽𝗹𝗶𝘁 𝗲𝘅𝘁𝗿𝗮𝗰𝘁𝗶𝗼𝗻 𝗶𝗻𝘁𝗼 𝘁𝘄𝗼 𝗰𝗮𝘁𝗲𝗴𝗼𝗿𝗶𝗲𝘀

Product facts get a source id, so every claim can be cited, not paraphrased from memory. Style signals get flagged as a starting guess that the user has to confirm, not something the system assumes is settled.

{
  "product_fact": {
    "id": "de7d26b4-865c-44a5-9ef0-137830dcf39c",
    "claim": "Batch a month of social content in one 3-hour session using five passes.",
    "source_url": "https://cadencz.com/blog/social-media-batching-founders",
    "confidence": "extracted"
  },
  "style_constraints": {
    "max_sentence_words": 22,
    "emoji_use": "none",
    "forbidden_terms": ["revolutionary", "game-changing", "guaranteed"],
    "status": "needs_user_confirmation"
  }
}

Notice the two objects don't share a status field by accident. A product fact is either sourced or it isn't. A style constraint is either confirmed by a human or it's a guess dressed up as a fact.

𝗧𝗵𝗲 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆 𝘁𝗵𝗮𝘁 𝗮𝗽𝗽𝗹𝗶𝗲𝘀 𝗽𝗮𝘀𝘁 𝗼𝘂𝗿 𝗽𝗿𝗼𝗱𝘂𝗰𝘁

Any pipeline that extracts facts from a document and later generates text from them needs to store the citation with the fact, not just the fact. Without the source id, your generation step has no way to distinguish "I read this on their pricing page" from "I'm pretty sure this is the kind of thing they'd say." Those feel identical at generation time. They are not identical in cost when a claim turns out to be wrong.

If you're building anything that reads a URL and outputs prose in someone's voice, treat facts and style as two different extraction problems with two different confidence rules. One can be scraped. The other has to be asked.

Every crowded software category has the same failure mode for new entrants.

akshay sharma — Sun, 06 Sep 2026 10:15:16 +0000

Every crowded software category has the same failure mode for new entrants.

The new product looks at the market leader's feature list and tries to match it, item by item. Scheduling, analytics, team seats, approval flows, integrations. By the time the checklist is done, the product is a slightly worse copy of something that already exists.

Matching every feature is not a strategy. It is an admission that you don't know what you're for.

The alternative is narrower and less comfortable. Pick one gap the incumbents leave open, usually because fixing it would mean rebuilding something core to how they already work. Then build only that, deeper than anyone else has bothered to.

This is uncomfortable because it means shipping a product that is visibly missing things reviewers will ask about. No team permissions. No custom reports. No fifteen integrations. Early customers will notice the gaps before they notice the one thing you actually solved.

That tradeoff is the point, not a flaw. A team that spreads its build hours across twelve features evenly ends up mediocre at twelve things. A team that spends the same hours on one real gap ends up genuinely good at one thing, which is usually enough to win a specific type of user.

The hard part isn't deciding to focus. It's picking the right gap. Not every unmet need is worth owning. Some gaps exist because the feature is genuinely hard to build well; others exist because incumbents decided it wasn't worth their time, which is a much better signal.

A useful test: does fixing this gap require the incumbent to break something their current customers depend on? If yes, they're structurally slow to copy you. If no, your window is short and you should assume they'll ship it in a quarter.

Being new is a disadvantage in almost every dimension except one. You get to be unremarkable at fewer things because nobody expects you to have built everything yet.

Once the product has traction, the feature list will grow to look like everyone else's eventually. But it earns the right to grow by being clearly better at one thing first, not by looking complete on day one.

What's the gap you're betting on, and could an incumbent copy it in a single sprint?

Retrying a failed job feels like the safe default. Sometimes it just delays a failure you already know is coming.

akshay sharma — Sun, 06 Sep 2026 04:30:15 +0000

Retrying a failed job feels like the safe default. Sometimes it just delays a failure you already know is coming.

We ran into this while building the scheduler behind Cadencz. A batch of posts failed to publish, and the naive fix was to retry the whole batch. That turned one bad API key into hours of wasted retries across jobs that had nothing wrong with them.

The fix was splitting errors into two categories at the job level, not the batch level.

Permanent errors don't deserve a retry. A deleted social account. Revoked OAuth credentials. A malformed payload that will never parse. Retrying these wastes queue capacity and delays the alert a human actually needs to see.

Transient errors deserve a retry, with backoff. A timeout from the platform API. A rate limit response. A brief network blip. These resolve on their own, and exponential backoff stops you from hammering a service that's already struggling.

Why job-level matters more than batch-level: a batch of 50 scheduled posts might contain one job with a dead token and 49 jobs that are perfectly fine. Failing the whole batch on that one error either stalls 49 healthy jobs or forces a full retry that repeats the same dead job 50 times.

Tagging the error type at the point of failure, inside the job itself, lets the queue route each job correctly. Dead jobs go to a dead-letter queue for a human to fix. Transient jobs go back with backoff. Healthy jobs keep moving.

The practical rule: classify the error before you decide the retry policy. Not all failures are the same problem, so they shouldn't get the same fix.

What error taxonomy does your queue use, and where did the batch-level assumption break down for you?

A build note worth sharing: before writing any spec for Cadencz, we picked the closest existing competitor and used its feature

akshay sharma — Sat, 05 Sep 2026 10:45:21 +0000

A build note worth sharing: before writing any spec for Cadencz, we picked the closest existing competitor and used its feature list as a checklist, not a spec to copy.

The competitor here is Postiz. It has scheduling, multi-platform posting, analytics, team seats, and a handful of integrations. That list is useful for exactly one reason: it tells you what's table stakes in this category.

Table stakes means users expect it by default. If you skip it, they notice the gap immediately. That's different from a feature that actually differentiates you.

The mistake we didn't make was treating that list as a roadmap. Matching every item feature-for-feature just makes you a slower, later copy of something that already exists.

The move that actually helped: going through the list and marking each item as "must have in v1," "wait," or "never building this." Most items landed in "wait." A few landed in "never," because they solve a problem our actual users don't have.

That third bucket is the one people skip. It's easy to add things a competitor has just because they have them. It's harder to say a feature is irrelevant to your specific user and mean it.

For Cadencz, that meant skipping generic scheduling depth in v1. Solo creators and founders don't need twelve platform integrations on day one. They need one thing done well: a system that reduces the blank-editor problem, not a scheduler with more toggles.

The concrete takeaway: pick your closest competitor, list their features, and sort each one into ship-now, ship-later, or skip-forever. The skip-forever column is where your actual product decisions live, not the ship-now column.

If you're building something in a crowded category, try this before writing your own feature list from scratch. It's faster than brainstorming from zero, and it forces you to justify every omission instead of every addition.

The scariest bug in a scheduling system isn't the one that crashes.

akshay sharma — Sat, 05 Sep 2026 03:30:24 +0000

The scariest bug in a scheduling system isn't the one that crashes.

A crash is loud. It throws a stack trace, pages someone, shows up in logs within seconds. Everyone knows something broke, and the fix starts immediately.

The dangerous failure is quieter. A job sits in the queue, waits for its scheduled time, and then just doesn't run. No exception. No error toast. No entry in the dead-letter table. The post that was supposed to go out at 9am simply never does, and nothing in the system objects.

This matters more in queue-based systems than almost anywhere else in software. A queue's whole job is to hold work until the right moment, then execute it. If that handoff fails silently, the system looks healthy while it's actually broken. Health checks pass. The API returns 200s. The only signal is a gap where a post should have been.

Trust erodes faster from silence than from noise. A user who sees a clear error can wait, retry, or work around it. A user who sees nothing assumes the system is fine, until they check their profile and realize three scheduled posts never went out. By the time they notice, they've already stopped trusting the schedule.

This is why "fail loud" belongs in the design of any queue-based system, not just social schedulers. Every job needs a terminal state that's visible somewhere a human will actually look: succeeded, failed with a reason, or retried and exhausted. A job that just vanishes from the queue without writing to any of those states is a design gap, not an edge case.

In practice this means treating the absence of a completion event as seriously as an explicit failure event. If a job was scheduled and its scheduled time has passed with no success record, that's a signal worth alerting on, even if no exception was ever thrown. Silence is data. Systems that only alert on thrown errors miss the failures that matter most, the ones where nothing happened at all.

If you're building anything with delayed execution, worth auditing: does every job either succeed or leave a trace of why it didn't? If the answer involves checking multiple tables and hoping the logs line up, that's the silent failure mode waiting to happen.

Most social tools default to team assumptions: roles, approval chains, someone reviewing someone else's draft before it goes liv

akshay sharma — Fri, 04 Sep 2026 10:30:20 +0000

Most social tools default to team assumptions: roles, approval chains, someone reviewing someone else's draft before it goes live.

That default makes sense for a marketing team. It makes no sense for a solo founder deciding, alone, whether a post is good enough.

When we scoped Cadence, the ship plan started by naming the audience precisely: solo creators and founders, not teams. Postiz was the checklist, mainly to see what we could skip.

Skipping matters more than adding here. Multi-seat permissions are real engineering effort: roles, invite flows, activity logs, edge cases around who can edit what. For a team, that's core. For one person, it's dead weight that adds complexity nobody uses.

Approval workflows have the same problem. A review step assumes two people: one who drafts, one who signs off. A solo founder is both. Building a queue for a decision one person already made just adds clicks between writing and publishing.

So the version-one list looks different once you take the audience seriously. No seats. No pending-review states. No notification system for approvals that never happen. What's left is the part that actually matters for one person working alone: fast drafting, scheduling that doesn't fight you, and a clear signal for what to publish next.

This is the part that's easy to miss when you copy a competitor's feature list wholesale. A feature isn't neutral. It carries an assumption about who's using it and how they decide. Copy the feature without checking the assumption, and you inherit workflow overhead built for a problem you don't have.

If you're building for one, the useful question isn't "what do other tools have." It's "what decision is this feature assuming, and does my user actually make that decision alone."

What would you cut first if you built for one person instead of a team?