Sprint-Based Svelte and SvelteKit Development

Two weeks. $6,000. One engineer. Something deployable at the end.

A sprint is a fixed-scope, fixed-price chunk of Svelte or SvelteKit work I can take from "kickoff call" to "deployed and you can use it" in ten working days. No hourly billing, no long-term contract, no agency layers between you and the code.

If the work is bigger than one sprint, we run consecutive sprints. Each one independently scoped. Each one with a real deliverable at the end. You can pause between any two. You can stop at any sprint boundary. The work compounds, but the commitment doesn't.

I've shipped this way for the last three years. It's the most honest cadence I've found for client work: long enough to do something real, short enough that nobody's wondering where the money went.

What you get for $6,000 / 2 weeks

• One engineer on the project, start to finish. Me. No handoffs, no mid-sprint swaps, no junior touching the code.

• A 30-minute scope call before the sprint to agree on what we're building.

• A 30-minute mid-sprint sync to talk through blockers and let you steer.

• Async updates throughout the sprint, pushed to GitHub or whatever's clearer, on whichever channel you already use (Slack, email, Basecamp, Linear).

• Production-ready code: typed Svelte and SvelteKit, accessibility-tested, performance-checked, deployed somewhere you can use it.

• Code review and PRs you can actually read, not a 5,000-line "feature merge" you have to take on faith.

• A short Loom or doc at sprint end explaining what shipped, what's outstanding, and what the next sprint could tackle.

You own the code from day one. GitHub commit access from the first PR. If we stop after sprint one, the work is yours, no asterisks.

What a sprint looks like

A concrete example, taken from a recent typical shape.

The brief. "We're a SaaS team with an existing SvelteKit app. We need to add a dashboard with real-time data, a settings UI for managing API keys, and we're stuck on auth. Can you ship this in two weeks?"

Week one. I onboard to your repo, install locally, file a first tiny PR, a layout fix or a typo, something small that proves I have access and can ship. Then I build the dashboard with SvelteKit load streams and a websocket. Build the settings UI with Zod and a real validation flow. PRs land in chunks of 200–400 lines, each one reviewable in a coffee-break.

Mid-sprint sync. Day eight, 30 minutes. I show you what's working. You tell me what feels off. We adjust. If auth is a one-day fix, this is when we decide to bundle it.

Week two. Edge cases, loading states, accessibility audit, performance pass, deploy. By Friday, the new dashboard is live, the settings UI is behind a feature flag if you want to QA first, and auth is either fixed or explicitly scoped for sprint two.

Sprint end. A 5-minute Loom walking through what changed and why. You can use it Monday.

The actual shape varies. Sometimes the work is a redesign, sometimes a migration, sometimes a greenfield MVP. The cadence is the same.

How it works

01 / Scope. A 30-minute call to figure out the work. You walk me through what you need. I'll tell you, honestly, whether one sprint, multiple sprints, or no sprint is the right shape. If it's a fit, we plan the first cycle on the same call. If it's not, I'll point you somewhere that fits better. No sales call.

02 / Setup. I slot into your tools. GitHub, Jira, Slack, Notion, Linear or whatever you already use. No tool migration. If you don't have a setup yet, I run sprints in Basecamp and pull you in.

03 / Build. Two weeks heads-down with one mid-sprint sync. Async updates as I go. PRs are small, frequent, and reviewable. You always know where the work stands.

04 / Ship. Working code at the end of week two. You decide what's next. Book another sprint, pause indefinitely, or wrap. No pressure to extend, no contract to exit.

Why this shape

Vs. hourly billing. Hourly billing makes us adversaries: you want me to work fewer hours, I want to log more. Fixed sprints align us. I want to ship the scope as efficiently as possible. You want the same. Same goal, no clock-watching.

Vs. project-based pricing. Project-based pricing requires me to know upfront how long a project will take. Most projects don't fit cleanly in that frame, and the ones that do tend to balloon because nobody wants to renegotiate scope mid-flight. Sprints make "renegotiate scope" the default at every two-week boundary.

Vs. retainers. Retainers reward me for showing up. Sprints reward me for shipping. I'd rather be paid for the second one.

Vs. hiring a full-timer. A senior Svelte (Kit) engineer in the US or EU costs roughly $180K–$220K all-in per year. That's about thirty sprints. Most of my clients don't have thirty sprints of work, they have three to ten, spaced out. Sprints fit that shape. When clients outgrow me, they hire.

Who this is for / not for

For. Founders and product teams that:

• Have a Svelte or SvelteKit project that needs to ship and a real deadline

• Want one experienced engineer who owns the work start to finish, not an agency

• Want to start small (one sprint, no commitment) and scale up if it works

• Already have a stack and just need someone who can plug in

Not for. People who need:

• Twenty engineers (I am one engineer)

• Procurement-heavy enterprise contracts (I'm a one-person LLC)

• Non-Svelte stacks (I do Svelte and SvelteKit; I'll point you elsewhere otherwise)

• Long-term staffing (sprints are project work, not headcount replacement)

• Design from scratch (I work with designers but don't replace them; if you don't have one, I have a few I work with regularly)

I'd rather tell you "no" upfront than pretend to be the right fit and miss the mark in week two.

Pricing

$6,000 per two-week sprint. Paid upfront, before the sprint starts. Same price every sprint, regardless of complexity, deadline, or how many Slack messages you send.

No additional fees. No retainer, no setup fee, no hourly overflow, no "this took longer than expected" addendum.

Cancel between sprints. If you don't want a second sprint, you don't book a second sprint. If you want to pause for two months and come back, the rate is the same when you do.

First-sprint refund. If the first sprint doesn't ship something usable, you get a full refund. I've never had to issue one, but the option exists because it should.

Ready?

If your project sounds like it might fit (a real Svelte or SvelteKit app, a real deadline, real scope), send me a paragraph. I'll tell you whether a sprint is the right shape, usually within a day. No discovery call required.