Validation on Shane's Personal Blog

Chapter 10: The Push

Mon, 10 Nov 2025 00:00:00 GMT

Chapter 10: The Push

January. Balance: $1,510. Rent due in eight days.

Alex covers January—one month grace. After that: revenue, funding, or something.

The prototype is live. Sixty-seven users. Sarah Chen forwarded it to Oregon colleagues—four teachers want to pilot with 120 students starting next week.

The biggest test yet.

Server barely handled 67 concurrent users. 120 might break it. Database upgrade: $80/month.

“If it crashes when teachers are watching, we’re done,” Alex says.

David upgrades. Doesn’t think about February.

Balance: $1,430.

Oregon pilot launches. David watches the dashboard. Users climb: 12, 28, 71, 89.

Server response time spikes. Timeouts. Three error screens.

David’s hands shake. He refreshes.

The graphs render. Slow. But they render.

Peak: 124 concurrent users.

It holds.

First week metrics:

124 students
34-minute average sessions
67% return rate

Teacher feedback: “Engaged.” “Unusual.” “Too early to tell.”

Not transformative. Not revolutionary. Just… engaged.

Balance: $1,210. Rent due in three days.

His mother calls. “Can you pay rent?”

“No.”

Silence. “How much?”

“Sixteen hundred.”

“Your father and I will cover it. This is a loan. And David—this is the last time. If you don’t have money by March, you need a real job.”

Her voice cracks. Terrified, not angry.

“I understand. Thank you.”

“Are you eating?”

“Mostly rice and eggs.”

“You need vegetables. Call me next week.”

“I will. Love you.”

The transfer arrives. $1,600. Balance: $2,810.

Eight weeks until March.

January: The numbers grow. 180 users, 220, 287 by month’s end.

Teacher feedback: behavioral observations. Students asking to use it. Engagement. “Unusual.”

Not revolutionary. Not transformative. Just… engaged.

David pitches fifteen investors. Twelve auto-responses. One rejection. Two interested.

One stops responding. Seedling Ventures schedules a call: February 2nd.

Everything riding on thirty minutes.

Late January. 11 PM. David should sleep. Instead he opens the product.

Types: “Why do I need to learn calculus?”

An interactive demo loads. Car in tunnel. Moving 60 mph. Where is it after 30 seconds?

A slider: “Your guess.”

He guesses 0.5 miles.

“Good! You just used calculus—rate of change to position.”

“But what if speed changes?”

The speed becomes a curve. He can manipulate it. Accelerate. Decelerate. Watch position change in real-time.

Five minutes of playing. Then: “Notice the relationship?”

“When the curve goes up, distance increases faster,” David types.

“Exactly! You discovered the fundamental theorem of calculus.”

Options branch: Physics. Economics. Biology. Programming.

This is it. Not lectures. Discovery. A kid asking “why do I need this?” gets to play first, discover patterns, then learn formulas.

Learning calculus while learning physics, coding, thinking. Multiple skills. Organic. Curiosity-driven.

David writes the investor pitch until 2 AM. The experience, not features. Discovery, not delivery.

Will investors care? Or just want revenue numbers?

He doesn’t know.

But now he can show them what’s different.

February 2nd. Seedling Ventures call.

David hasn’t slept. Ran on two hours last night, fixing a rendering bug he found at midnight.

The Zoom opens. Jessica Martinez—partner at Seedling. Mid-forties. Sharp. Behind her, two other people David wasn’t expecting. Michael Chen, another partner. Sara Rodriguez, analyst.

Three people. Not one. David’s stomach tightens.

“Thanks for making time,” Jessica says. “We’ve been following your progress. Intrigued by the approach. Walk us through it?”

David shares his screen. Opens the prototype. His hands are shaking slightly. He hopes they can’t see.

“Traditional education asks students to memorize,” he says. “We start with curiosity. Let me show you—”

He types into the demo: “Why do I need to learn calculus?”

The interactive loads. Car in tunnel. Variables. The clean interface he spent hours perfecting.

“Students manipulate this themselves,” David says. “They discover the relationship between—”

The screen freezes.

David’s heart stops.

The car animation is stuck. The slider won’t move. The browser is thinking. Thinking. Thinking.

“Sorry,” David says, voice tight. “Let me refresh—”

He refreshes. The page reloads slowly. Too slowly. Thirty seconds of Jessica, Michael, and Sara watching a loading spinner.

Finally, it loads. David tries the slider again.

It works this time. The car moves. Numbers update.

“See,” David says, trying to recover. “They discover rates of change intuitively before we—”

The screen goes white.

David stares in horror. White screen. Nothing. Browser crashed.

“I’m so sorry,” he says. His hands are shaking visibly now. “This was working an hour ago. I don’t know what—”

“Is this a common problem?” Michael asks. Not mean. Just assessing.

“No. I mean—we’ve had server issues with scaling, but the demos have been solid. This is—” David stops. He sounds defensive. Desperate.

Alex jumps in from off-camera. “I can pull up the backup instance. Give us thirty seconds.”

Those thirty seconds feel like an hour.

Jessica waits. Professional. Neutral. The other two are typing. Probably notes. Probably: “Demo crashed. Technical instability.”

Alex gets the backup running. David shares the new screen.

“Okay,” David says. Trying to sound confident. Failing. “Let me try this again.”

This time it works. The calculus demo runs. David talks through it. Shows the knowledge graph. The connections. The curiosity-driven flow.

But the energy is gone. The magic moment ruined. He can see it in their faces. Polite interest. Not excitement.

After fifteen minutes, Jessica stops him. “This is interesting. Can you talk about traction?”

“Three hundred users. Oregon teachers. Thirty-one minute average sessions. High engagement.”

“Revenue?”

“None yet. But we have a school district interested. Willow Creek. 800 students. Free pilot, then paid contract if it works.”

“And your runway?”

David hesitates. Should he lie? Stretch it?

“Six weeks,” he says. “Maybe seven.”

Silence.

Michael speaks. “That’s not a lot of time.”

“I know. But we’re close. This pilot could be the proof point we need.”

Sara jumps in. “What if the pilot doesn’t convert? What’s your backup plan?”

David doesn’t have one. Can’t say that.

“We believe in the product. The engagement metrics show students want this. It’s a matter of finding the right school willing to pay for it.”

More silence.

Jessica exchanges a glance with Michael. Some unspoken conversation.

“Okay,” Jessica says. “Here’s where we are. The mission resonates. The approach is interesting. But the demo crashing mid-pitch is concerning. And six weeks is not enough time to prove this out.”

David’s chest tightens. This is a rejection. He can feel it coming.

“However,” Jessica continues, “I do think there’s something here. What if we did a bridge round? Small. $50k. Six months. Convertible note at a $5M cap. That gives you runway to run the pilot and prove schools will pay. If you get to sustainable revenue, we’ll lead your seed round.”

David doesn’t dare speak. Afraid his voice will crack.

Alex off-camera: “What’s the minimum traction you’d need to see for the seed?”

“Three to five paying schools. $20k minimum annual revenue. Proof that the model works.”

“That’s doable,” Alex says.

Jessica looks at David. “But I need to be clear. This is conditional. The demo crashing today makes me nervous. If there are technical stability issues, or if the pilot fails, we’re out. This bridge is a bet on execution. Can you deliver?”

Can he deliver? David doesn’t know. Six weeks ago he was in the gray. Two months ago the prototype failed user testing. Every step forward reveals new problems.

But Jessica is offering $50,000. Six months of breathing room. A chance.

“Yes,” David says. “We can deliver.”

“Alright.” Jessica types something. “We’ll send a term sheet by end of week. Get it signed and we’ll wire the funds. But David—” She looks directly at him. “Fix the technical issues. If you’re pitching schools and the demo crashes, you’re done. Understand?”

“Understood.”

The call ends.

David sits in silence. Stares at the blank Zoom screen.

“That was close,” Alex says, coming into frame.

“Close to what? Success or disaster?”

“Both.”

David opens the browser console. Scrolls through the error logs. There—a memory leak. He’s been running the demo dozens of times while testing. The browser couldn’t handle it.

A bug he should have caught. Would have caught if he’d slept. If he’d tested properly.

Instead, he almost blew the entire pitch.

“$50k,” Alex says. “That’s huge.”

“If we can fix the bugs. If the pilot works. If schools actually pay.”

“One step at a time.”

David nods. But his hands are still shaking.

They almost lost it. One crashed demo away from Jessica saying “thanks, but no thanks.”

And now—now they have six months to prove this works. To get paying customers. To show that ten months of suffering wasn’t for nothing.

The pressure is enormous. The margin for error is zero.

But they have $50,000.

They have oxygen.

“We should celebrate,” Alex says. “This is good news.”

“I need to fix the memory leak first.”

“David—”

“I almost blew it, Alex. I almost crashed the only pitch that mattered. I can’t—” He stops. Takes a breath. “I need to fix this. Then we celebrate.”

Alex doesn’t argue.

David opens the code. Finds the leak. Fixes it. Tests it twenty times. Thirty. Fifty.

Doesn’t crash.

Around 7 PM, he finally closes the laptop.

“Okay,” he says. “Now we celebrate.”

They order pizza. The good kind. Not the cheapest option. Actual toppings.

While they wait, David sits with the reality of it.

They got funding. Barely. By the thinnest margin. One crashed demo away from failure.

But they got it.

$50,000. Six months. One more chance to prove this vision is real.

Not because he pitched perfectly. But because Jessica saw something worth betting on. Even after the demo crashed. Even after the disaster.

She believed enough to take the risk.

Now David has to prove she was right.

The term sheet arrives three days later. David reads it seventeen times. Signs it with a shaking hand.

The wire transfer hits on February 15th. $50,000. Six months of runway. Conditional on execution.

Alex nods off-screen.

“We’re in,” David says quietly.

But this time, he knows what he’s in for. The pressure. The expectations. The constant fear of technical failures. The knowledge that one more crashed demo could end everything.

Still.

They’re alive.

For now.

$50,000. Six months. Conditional on revenue.

Not a full seed. But oxygen.

David pays back his parents. Balance: $48,710.

Six months to prove this works.

Funding closes February 28th. $50k.

David repays his parents: $1,600. Balance: $48,490.

His mother calls. “You got funding?”

“A bridge round. Enough to keep going.”

“I’m proud of you. Don’t waste it.”

“I won’t.”

Mid-February. Email from Principal Anderson, Willow Creek School District:

“800-student pilot. Grades 6-8. Free trial starting March 30th. If it works, paid contract for next year. $8-10 per student. Interested?”

David reads it three times. This is the path to revenue.

“Absolutely.”

February 18th. District call.

Anderson: “What makes this different?”

David demos the calculus path. “They discover patterns before we teach formulas. Thirty-one minute sessions. Not forced. Chosen.”

Hayes (tech director): “State standards?”

“We don’t align directly. But when a kid spends 45 minutes following curiosity from calculus to physics to programming—they learn. Because they want to.”

Anderson: “Four-week pilot. 800 students. Starting March 30th. Free. If it works, $8/student annually.”

$6,400 first year. Not profit. But proof.

“We’re in.”

Five weeks to scale for 800 concurrent users.

Five weeks to prove this works.

February: Server upgrades. Security audits. New interactive demos.

Oregon metrics steady: 31 minutes, 71% return, “unusual engagement.”

Still no deep learning insights. Just engagement.

David works 14-hour days. Climate simulators. Music visualizers. Historical timelines.

Each following the pattern: Curiosity → Interaction → Discovery → Knowledge.

Math + coding. Science + systems thinking. History + data analysis.

Won’t know if it works until March. Until 800 students show if this vision is real.

February 28th. Evening.

David sits at his desk. The funding closed this morning. His parents are repaid. The servers are upgraded. The district pilot is scheduled.

Everything that can be ready is ready.

Now he waits.

His phone buzzes. An email from one of the Oregon teachers.

Subject: “Interesting observation.”

He opens it.

“David—I’ve been watching my students use your platform for six weeks now. I wanted to wait before saying anything. Here’s what I’m noticing: My students who usually struggle are asking different questions. Not ‘what’s the right answer?’ but ‘what happens if I change this?’ One student spent three weeks exploring climate science through your simulators. He failed my last test. But yesterday he explained the greenhouse effect to the class better than I could have. He didn’t memorize it. He discovered it. I don’t know what you’re building, but it’s reaching kids differently. - Mr. Thompson”

David reads it twice.

Six weeks. That’s how long it took. Six weeks of consistent use before the learning showed up. Before the difference became visible.

Not immediate feedback. Not instant transformation.

Slow. Organic. Real.

A student who fails tests but understands deeply. Who can explain concepts because he discovered them himself.

That’s the vision. That’s what the platform was built for.

David saves the email. Adds it to the folder labeled “Why.”

The district pilot starts in four weeks. Eight hundred students. Four weeks of use. If Mr. Thompson’s observation is the pattern, they won’t see the deep learning until late April. Until after the pilot technically ends.

But if it’s real—if students are actually learning differently—it’ll show.

In time.

David closes his laptop. The apartment is quiet. Alex has gone home. The city glows through the window.

Tomorrow he’ll keep preparing. Keep building. Keep hoping the vision holds.

But tonight—for the first time in weeks—David feels something that isn’t just anxiety.

Not confidence. Not certainty.

Just… possibility.

The kind that comes from seeing one student fail a test but understand the material. From knowing that learning and testing aren’t the same thing. From building something that values discovery over memorization.

It might work.

Or it might not.

But at least now, he has time to find out.

David turns off the lights. The balance: $48,710.

The pilot: four weeks away.

The answer: coming soon.

He sleeps better than he has in months.

End of Chapter 10

From Pydantic to msgspec: A Migration Story About Validation and Control

Sun, 02 Nov 2025 00:00:00 GMT

The Migration That Made Me Question Everything

I thought I had Python validation figured out. Pydantic was my trusted companion—elegant, powerful, and seemingly complete. Why would I need anything else?

Then I decided to migrate a project from FastAPI to Litestar. The reasons were good: better performance, cleaner architecture, advanced SQLAlchemy integration. But there was a catch—Litestar favored msgspec over Pydantic. And msgspec? I’d barely heard of it.

“How hard could it be?” I thought. “Validation is validation, right?”

Wrong. So wrong.

The Pydantic Comfort Zone

Let me show you what I was used to. Here’s how I’d been writing validation for years:

from pydantic import BaseModel, EmailStr, field_validator

class UserRegistration(BaseModel):
    email: EmailStr  # Automatic email validation
    password: str
    age: int

    @field_validator('password')
    @classmethod
    def validate_password(cls, v: str) -> str:
        if len(v) < 8:
            raise ValueError('Password must be at least 8 characters')
        if not any(c.isupper() for c in v):
            raise ValueError('Password must contain uppercase letter')
        return v

    @field_validator('age')
    @classmethod
    def validate_age(cls, v: int) -> int:
        if v < 18:
            raise ValueError('Must be 18 or older')
        return v

# Usage in FastAPI
@app.post("/register")
async def register(data: UserRegistration):
    # If we get here, data is GUARANTEED valid
    # Everything is checked: types, email format, password rules, age
    user = await create_user(data.model_dump())
    return {"message": "User created"}

Beautiful, right? One model definition, all validation in one place. The moment you create a UserRegistration instance, Pydantic validates everything—types, formats, business rules. If the data reaches your endpoint handler, you know it’s valid.

This felt complete. Elegant. Right.

First Contact: Where Are My Validators?

Fast forward to my Litestar migration. I started converting my Pydantic models to msgspec:

import msgspec

class UserRegistration(msgspec.Struct):
    email: str
    password: str
    age: int

# Usage in Litestar
@post("/register")
async def register(data: UserRegistration) -> dict:
    # Wait... where do I put the email validation?
    # Where's my password strength check?
    # How do I validate age >= 18?
    user = await create_user(msgspec.to_builtins(data))
    return {"message": "User created"}

I stared at the screen, confused. Where were the decorators? Where was EmailStr? How do I add my custom validators?

I spent an embarrassing amount of time searching for “msgspec field_validator equivalent” and finding… nothing helpful.

My first thought: “This library is incomplete. How can people use this?”

My second thought: “Maybe I’m missing something.”

Spoiler: I was missing something big.

The Uncomfortable Truth: Validation Comes in Two Flavors

After hours of frustration (and reading way too much documentation), I had a realization: msgspec and Pydantic have fundamentally different philosophies about what validation means.

Here’s what finally clicked for me:

Pydantic’s Philosophy: “Everything, Everywhere, All at Once”

Pydantic believes validation should happen at the model boundary. When you create a model instance, everything gets validated—types, formats, business rules, constraints. The model definition is the single source of truth.

# With Pydantic: ONE validation point
user = UserRegistration(**incoming_data)
# ↑ If this succeeds, ALL validation passed
# Types? ✓  Email format? ✓  Password rules? ✓  Age check? ✓

msgspec’s Philosophy: “Fast Types, You Handle the Rest”

msgspec believes in separating concerns:

Type validation: Lightning-fast, automatic, guaranteed, Just like Pydantic
Business validation: Your application, your rules, your code

# With msgspec: TWO validation layers
user = UserRegistration(**incoming_data)
# ↑ Types validated (str, int, etc.) - FAST
# ↓ Business rules - YOUR CODE
if len(user.password) < 8:
    raise ValueError("Password too short")

This felt wrong at first. Why split validation? Isn’t Pydantic’s approach more… complete?

But then I started to understand the advantages.

The Lightbulb Moment: Explicit Control

Here’s what changed my mind: msgspec gives you explicit control over when and how business validation happens.

Let me show you what I mean with a real example from my migration.

The Password Reset Problem

In my app, users can register with a password OR reset their password. Different endpoints, different validation needs:

With Pydantic, I had to do this:

class UserRegistration(BaseModel):
    email: EmailStr
    password: str
    full_name: str

    @field_validator('password')
    @classmethod
    def validate_password(cls, v: str) -> str:
        # Always enforces strong password
        if len(v) < 8:
            raise ValueError('Password must be at least 8 characters')
        return v

class PasswordReset(BaseModel):
    email: EmailStr
    password: str
    reset_token: str

    @field_validator('password')
    @classmethod
    def validate_password(cls, v: str) -> str:
        # Duplicate validation code!
        if len(v) < 8:
            raise ValueError('Password must be at least 8 characters')
        return v

Notice the duplication? I’m defining the same password validation in two places. If I change the rules (say, require special characters), I need to update both validators.

With msgspec, I could do this:

class UserRegistration(msgspec.Struct):
    email: str
    password: str
    full_name: str

class PasswordReset(msgspec.Struct):
    email: str
    password: str
    reset_token: str

# Validation logic lives in ONE place - the service
class UserService:
    @staticmethod
    def validate_password(password: str) -> None:
        """Centralized password validation"""
        if len(password) < 8:
            raise ValueError("Password must be at least 8 characters")
        if not any(c.isupper() for c in password):
            raise ValueError("Password must contain uppercase")
        if not any(c.isdigit() for c in password):
            raise ValueError("Password must contain number")

    async def register(self, data: UserRegistration):
        self.validate_password(data.password)  # Reusable!
        # ... create user

    async def reset_password(self, data: PasswordReset):
        self.validate_password(data.password)  # Same validation!
        # ... reset password

Suddenly it clicked: by separating type validation from business validation, msgspec lets me reuse validation logic across different contexts.

Wait, But msgspec Structs CAN Have Methods

Here’s where I had another revelation. I assumed msgspec Structs were just dumb data containers. They’re not!

class UserRegistration(msgspec.Struct):
    email: str
    password: str
    age: int

    def validate(self) -> None:
        """Custom validation - attached to the model!"""
        # Email validation
        if "@" not in self.email or "." not in self.email.split("@")[-1]:
            raise ValueError("Invalid email format")

        # Password validation
        if len(self.password) < 8:
            raise ValueError("Password must be at least 8 characters")
        if not any(c.isupper() for c in self.password):
            raise ValueError("Password needs uppercase letter")

        # Age validation
        if self.age < 18:
            raise ValueError("Must be 18 or older")

# Usage in controller
@post("/register")
async def register(data: UserRegistration) -> dict:
    # Types already validated by msgspec
    # Business validation is explicit
    data.validate()

    user = await create_user(msgspec.to_builtins(data))
    return {"message": "User created"}

So I could attach validation to the model, just like Pydantic. The difference? It’s explicit. I call .validate() when I decide it’s time.

This gives me control Pydantic doesn’t:

Validate at different points in the request lifecycle
Skip validation for trusted internal calls
Customize validation based on context
Separate validation errors from deserialization errors

The Performance Surprise

I hadn’t even been thinking about performance—I just wanted my validation to work. But then I ran some benchmarks.

import msgspec
import pydantic
import time

class PydanticUser(pydantic.BaseModel):
    id: int
    email: str
    full_name: str
    is_active: bool

class MsgspecUser(msgspec.Struct):
    id: int
    email: str
    full_name: str
    is_active: bool

data = {
    "id": 12345,
    "email": "user@example.com",
    "full_name": "John Doe",
    "is_active": True
}

# Benchmark Pydantic
start = time.perf_counter()
for _ in range(100_000):
    user = PydanticUser(**data)
pydantic_time = time.perf_counter() - start

# Benchmark msgspec
start = time.perf_counter()
for _ in range(100_000):
    user = msgspec.convert(data, type=MsgspecUser)
msgspec_time = time.perf_counter() - start

print(f"Pydantic: {pydantic_time:.3f}s")
print(f"msgspec:  {msgspec_time:.3f}s")
print(f"msgspec is {pydantic_time / msgspec_time:.1f}x faster")

# Output (Using: Ubuntu 24.04.3 LTS, Python 3.14.0b2):
# Pydantic: 0.053s
# msgspec:  0.017s
# msgspec is 3.2x faster

3.2x faster. For type validation alone.

I wasn’t even optimizing for performance, but suddenly my API endpoints felt snappier. Response times dropped. Under load, the difference would be even more noticeable.

Side by Side: The Complete Picture

Let me show you both approaches for the same real-world scenario—user registration with email, password, and age validation.

The Pydantic Way

from pydantic import BaseModel, EmailStr, field_validator

class UserRegistration(BaseModel):
    email: EmailStr
    password: str
    age: int
    full_name: str | None = None

    @field_validator('password')
    @classmethod
    def validate_password(cls, v: str) -> str:
        if len(v) < 8:
            raise ValueError('Password must be at least 8 characters')
        if not any(c.isupper() for c in v):
            raise ValueError('Password must contain uppercase')
        if not any(c.isdigit() for c in v):
            raise ValueError('Password must contain number')
        return v

    @field_validator('age')
    @classmethod
    def validate_age(cls, v: int) -> int:
        if v < 18:
            raise ValueError('Must be 18 or older')
        if v > 120:
            raise ValueError('Invalid age')
        return v

# FastAPI endpoint
@app.post("/register")
async def register(data: UserRegistration):
    # Everything validated automatically
    user = await user_service.create(data.model_dump())
    return {"id": user.id}

Pros:

All validation in one place
Automatic on instantiation
EmailStr handles format validation
Clean endpoint code

Cons:

Validation logic tied to request model
Hard to reuse validators across models
Can’t skip validation for internal use
Slower serialization

The msgspec Way

import msgspec

class UserRegistration(msgspec.Struct):
    email: str
    password: str
    age: int
    full_name: str | None = None

    def validate(self) -> None:
        """Business validation - called when YOU want"""
        # Email validation
        if "@" not in self.email or "." not in self.email.split("@")[-1]:
            raise ValueError("Invalid email format")

        # Password validation
        if len(self.password) < 8:
            raise ValueError("Password must be at least 8 characters")
        if not any(c.isupper() for c in self.password):
            raise ValueError("Password must contain uppercase")
        if not any(c.isdigit() for c in self.password):
            raise ValueError("Password must contain number")

        # Age validation
        if self.age < 18:
            raise ValueError("Must be 18 or older")
        if self.age > 120:
            raise ValueError("Invalid age")

# Litestar endpoint
@post("/register")
async def register(data: UserRegistration) -> dict:
    # Types validated automatically by msgspec
    # Business validation is explicit
    data.validate()

    user = await user_service.create(msgspec.to_builtins(data))
    return {"id": user.id}

Pros:

Blazing fast type validation
Explicit validation control
Can reuse validation logic
Can skip validation when appropriate
Clear separation of concerns

Cons:

Must remember to call .validate()
No built-in EmailStr equivalent
More manual validation code
Endpoint code has one extra line

Alternative: Validation in Service Layer

With msgspec, you can also move validation to the service:

class UserRegistration(msgspec.Struct):
    email: str
    password: str
    age: int
    full_name: str | None = None

class UserService:
    async def create(self, data: dict) -> User:
        """Validate during creation"""
        # Email validation + uniqueness check
        if "@" not in data["email"]:
            raise ValueError("Invalid email")
        if await self.repository.email_exists(data["email"]):
            raise ValueError("Email already registered")

        # Password validation (reusable across endpoints!)
        self._validate_password(data["password"])

        # Age validation
        if data["age"] < 18:
            raise ValueError("Must be 18 or older")

        return await self.repository.create(data)

    @staticmethod
    def _validate_password(password: str) -> None:
        """Centralized password validation"""
        if len(password) < 8:
            raise ValueError("Password too short")
        # ... more checks

# Controller stays clean
@post("/register")
async def register(data: UserRegistration) -> dict:
    # Types validated by msgspec
    # Business rules validated in service
    user = await user_service.create(msgspec.to_builtins(data))
    return {"id": user.id}

This pattern centralizes business logic where it belongs—in the service layer, not the request model.

When to Use Which?

After living with both libraries, here’s my decision matrix:

Choose Pydantic When

You want automatic validation everywhere - Set it and forget it
You’re building a standard CRUD API - Pydantic’s patterns are well-established
Your team prefers “magic” - Less boilerplate, more automatic behavior
You need the ecosystem - Pydantic has integrations everywhere
Performance isn’t critical - Still fast enough for most use cases

Choose msgspec When

Performance matters - High-throughput APIs, real-time systems
You want explicit control - You decide when validation happens
You value separation of concerns - Business logic in services, not models
You’re using Litestar - Native integration, optimal performance
You need validation reuse - Share logic across different contexts

You Can Use Both

Here’s a secret: they can coexist. Use Pydantic for complex validation where you want the ecosystem, msgspec for high-performance paths.

# Pydantic for complex admin operations
class ComplexUserUpdate(BaseModel):
    # Use all of Pydantic's validation features
    ...

# msgspec for high-frequency endpoints
class UserListResponse(msgspec.Struct):
    # Fast serialization for list endpoints
    ...

What I Learned

This migration taught me that there’s no one “right” way to do validation. Pydantic and msgspec represent different trade-offs:

Pydantic says: “Validation should be automatic and comprehensive”
msgspec says: “Validation should be explicit and fast”

Both philosophies are valid. Both have their place.

I started this migration frustrated, thinking msgspec was incomplete. I ended it appreciating how explicit control over validation can actually make code clearer and more maintainable.

The .validate() call that felt like extra boilerplate? Now I see it as documentation—a clear signal that “validation happens here.” The manual validation methods? They’re reusable functions I can test independently.

And the performance? That was just a nice bonus I wasn’t even looking for.

The Migration Continues

My Litestar migration is still ongoing, but I’m no longer fighting msgspec. I’m embracing it. The initial confusion has given way to appreciation.

Would I go back to Pydantic for everything? No.

Would I use msgspec for everything? Also no.

The real lesson: understand your tools’ philosophies. Pydantic isn’t “complete” and msgspec isn’t “incomplete”—they’re just optimized for different values. Knowing when to use which makes you a better developer.

And sometimes, the libraries you think are missing features are actually giving you something more valuable: control.

(Written by Human, improved using AI where applicable.)