I have been working on pikku.dev, a typescript server library / framework that does most things and deploys in most places [1]
Been a project I was using for a few years now. Initially started off as express middleware with a few tools chained together to automate as much typing as possible which can run anywhere (similar to hono).
Around a year ago I decided to change the approach and write a layer to statically analyze the typescript code ontop of tsc and pull out as much meta as possible.
After that I went a little crazy and ultimately added wires to everything. HTTP, Websockets, Queues, Scheduled Jobs, etc. All totally agnostic (the core runtime is pretty tiny). So can run scheduled tasks on lambas / a cron job / pgadmin, deploy websockets serverless or local, run your queues again most queue provides, etc.
I then saw Vercels workflow runner and figured, well, I could try do better . Looked at other libraries out there and decided to include addons, which are pikku typescript packages that declare functions which can be automatically imported into your app and are responsible for their own service initialization. If your used to writing n8n plugins be awesome to hear what you think about this approach!
That sort of required me to create a console to view workflows (otherwise what's the point right?). And since everything is statically extracted during runtime we can pretty much just visualise the entire codebase. So all your functions, what permissions each have, etc etc. The idea behind the console is that it doesn't have an actual backend. You install an addon into your own codebase, permission it as you see fit and you point the console towards it. That means you have a unified permissions/auth system as everything else.
Figured the last part was creating an AI agent to wrap it all together. Which is almost there. Subagent flows, tools, approvals, ai middleware that can turn input and output into voices, its does a bit.
Ultimately the idea is you write a function once, and it can be consumed as an AI tool, a workflow step, by a http route, a cron job, a gateway (like whatsapp) (I liked openclaw approach so figured.. why not ).
A function is the source of truth, so is permissioned / authenticated. Been alot of heavy development since I'm building a 'BuildYourAgent' portal ontop that pretty much takes an openapi doc and turns it into an MCP server / hooks it up to an agent / gives you a CLI around it so it can integrate with all the crazy wild west approaches, while you know, still allowing us to maintain sanity and build servers that don't hallucinate and burn forests down.
Curious on thoughts! Bit of a rambling explanation. I hope the website does a better job! Lots of content helped with AI (I prefer speaking tech, but doesn't always transition well).
Also, looking for a potential cofounder to help balance that out! If your interested in potentially working together / adopting pikku feel free to leave a comment / ping me an email
Pikku builds a full type contract between your backend and frontend. It doesn’t ship a runtime SDK just typed native fetch calls / websockets / queue clients so your frontend gets zero added bundle size and fully inferred request/response types out of the box.
The framework is tree-shaken at the function level, so you can deploy only what’s needed (plus its dependencies) as a binary, Docker image, or serverless functions. Switch cloud providers or queue systems freely, no rewrites, just switch runtimes.
Auth, permissions, and middleware live directly at the function level, giving you a single consistent entrypoint across all transports.
It also supports Next.js-style "use server" patterns — you can call backend functions directly in SSR while keeping them accessible over HTTP for external use.
There’s even a CLI mode where you can run commands on a server and stream live output to a tiny local client — same code, same types.
I'm about to release the next version that allow supports workflows similar to those just released by Vercel or by Cloudflare Workflows.
Would love to hear your thoughts! There's even more on the roadmap :D
The goal is to provide a fully typed nodeJS framework that allows you to write a typescript function once and then decide whether to wire it up to http, websocket, queues, scheduled tasks, mcp server, cli and other interactions.
You can switch between serverless and server deployments without any refactoring / completely agnostic to whatever platform your running it on
It also provides services, permissions, auth, eventhub, advanced tree shaking, middleware, schema generation and validation and more
The way it works is by scanning your project via the typescript compiler and generating a bootstrap file that imports everything you need (hence tree shaking), and allows you to filter down your backend to only the endpoints needed (great to pluck out individual entry points for serverless). It also generates types fetch, rpc, websocket and queue client files. Types is pretty much most of what pikku is about.
Think honoJS and nestJS sort of combined together and also decided to support most server standards / not just http.
Website needs love, currently working on a release to support CLI support and full tree shaking.
I agree framing pikku has been a pretty hard challenge for me.
It supports different runtimes in the sense of deno / bun or custom nodeJS runtimes in the cloud, but ultimately relies purely on typescript / a JavaScript compatible backend.
It’s less of a webserver and more of a lightweight framework though, since it also supports CLIs or Frontend SDKs / isn’t tied to running an actual server.
I agree it’s pretty frustrating, but I do really like the SSR capabilities
I’m divide my frontend and backend via pikku, that way I can continue using normal server side functions but optionally spin up a seperate api service if needed.
Haven’t really tested it on vercel as much, but it ignores middleware on the nextJS side unless it’s for frontend code.
Most backends still treat HTTP as the “first-class citizen,” and everything else (WebSockets, queues, cron, mcp) feels bolted on with custom wiring and their own typings if any.
Pikku aims to take a different approach:
- Define a function once → invoke it from HTTP, WebSockets, queues, cron, or even Postgres.
- Deployment is your choice: single process, containers, serverless, or workers. Pick your own queue library, deploy scheduled tasks via lambda, the choice is endless.
- Fully typed, end-to-end → auto-generated clients are tiny, just thin wrappers over existing libs.
Built-in support for services, middleware, permissions, and auth.
I would recommend looking into being able to recognise ‘thought viruses’
A book that really helped me was ‘Stop overthinking’ by Nick Trenton. I still have those thoughts, Anxiety isn’t the easiest thing to get rid of.
Find what it is that you enjoy, build habits (tiny habits / atomic habits are great references) and you might find that just moving a tiny bit in the direction that makes you happy might compound over time.
Success isn’t always about careers or large paydays. Your health, relationships, hobbies, identity and sanity play a big part of that as well.
I have friends who moved to other countries and restarted their lives at the age of 35/40, and I met people in their 70s who done the same.
SEEKING WORK | Berlin (CET/CEST) | Remote | Senior Full-Stack & Cloud Specialist
I’m a senior developer and infrastructure consultant with 15+ years of experience
— available for part-time work (24h/week). I help teams move fast without breaking things, bringing deep infrastructure expertise alongside strong full-stack execution.
• Delivery-First Mindset: Recently helped a client setup up CI/CD, staging, and production environments via Kubernetes — from scratch to deploy — in just 3 weeks part-time
What I’m Looking For:
Teams with meaningful technical challenges — ideally past the MVP/PoC stage and ready to do things properly. I’m most effective where there’s a need to scale infra, clean up dev workflows, or modernize architecture.
Engagement Style:
• Part-time (24h/week)
• Open to short/middle term high-impact contracts, retainers, or embedded support
SEEKING WORK | Berlin (CET/CEST) | Remote | Senior Full-Stack & Cloud Specialist | Part-Time (24h/week)
I’m a senior developer and infrastructure consultant with 15+ years of experience — available for part-time work (24h/week). I help teams move fast without breaking things, bringing deep infrastructure expertise alongside strong full-stack execution.
• Delivery-First Mindset: Recently helped a client setup up CI/CD, staging, and production environments via Kubernetes and compliant — from scratch to deploy — in just 3 weeks part-time
What I’m Looking For:
Teams with meaningful technical challenges — ideally past the MVP/PoC stage and ready to do things properly. I’m most effective where there’s a need to scale infra, clean up dev workflows, or modernize architecture.
Engagement Style:
• Part-time (24h/week)
• Open to short/middle term high-impact contracts, retainers, or embedded support
It’s a TypeScript web framework that’s runtime agnostic, so it can work on serverless and servers (similar to Hono).
What’s different is that the focus is primarily just on TypeScript. There’s a CLI tool that inspects all the project code and generates loads of metadata. This can include:
• services used
• all the HTTP routes, inputs and outputs
• OpenAPI documentation
• schemas to validate against
• typed fetch client
• typed WebSocket client
(and more)
The design decision was also to make it follow a function-based approach, which means your product code is just functions (that get given all the services required). And you have controllers that wire them up to different transport protocols.
This allows interesting design concepts, like writing WebSocket code via serverless format, while allowing it to be deployed via a single process or distributed/serverless. Or progressive enhancement, allowing backend functions to work as HTTP, but also work via Server-Sent Events if a stream is provided.
It also allows functions to be called directly from Next.js and full-stack development frameworks without needing to run on a separate server or use their API endpoints (not a huge advocate, but it helps a lot with SSR). Gave a talk about that last week at the Node.js meetup in Berlin.
It’s still not 1.0 and there are breaking changes while I include more use cases.
Upcoming changes:
• use Request and Response objects to make it truly runtime agnostic (currently each adapter has its own thin layer, which tbf is still needed by many that don’t adopt the web spec)
• smarter code splitting (this will reduce bundle size by tree-shaking anything not needed on a per-function basis)
SEEKING WORK | Berlin (CET/CEST) | Remote | Part-time | Senior Full-Stack Developer and Cloud Specialist with 14+ years of experience seeking part-time work.
Experience Highlights:
- Fintech: 5 years with banks and hedge funds - Co-founder: deepstreamHub.com
- AI Projects: Tazamun on mindfulness and mental health
Seeking a part-time role with a motivated team. If you need senior expertise in infrastructure optimization or full-stack development without the commitment of a full-time hire, let's connect!
Been a project I was using for a few years now. Initially started off as express middleware with a few tools chained together to automate as much typing as possible which can run anywhere (similar to hono).
Around a year ago I decided to change the approach and write a layer to statically analyze the typescript code ontop of tsc and pull out as much meta as possible.
After that I went a little crazy and ultimately added wires to everything. HTTP, Websockets, Queues, Scheduled Jobs, etc. All totally agnostic (the core runtime is pretty tiny). So can run scheduled tasks on lambas / a cron job / pgadmin, deploy websockets serverless or local, run your queues again most queue provides, etc.
I then saw Vercels workflow runner and figured, well, I could try do better . Looked at other libraries out there and decided to include addons, which are pikku typescript packages that declare functions which can be automatically imported into your app and are responsible for their own service initialization. If your used to writing n8n plugins be awesome to hear what you think about this approach!
That sort of required me to create a console to view workflows (otherwise what's the point right?). And since everything is statically extracted during runtime we can pretty much just visualise the entire codebase. So all your functions, what permissions each have, etc etc. The idea behind the console is that it doesn't have an actual backend. You install an addon into your own codebase, permission it as you see fit and you point the console towards it. That means you have a unified permissions/auth system as everything else.
Figured the last part was creating an AI agent to wrap it all together. Which is almost there. Subagent flows, tools, approvals, ai middleware that can turn input and output into voices, its does a bit.
Ultimately the idea is you write a function once, and it can be consumed as an AI tool, a workflow step, by a http route, a cron job, a gateway (like whatsapp) (I liked openclaw approach so figured.. why not ).
A function is the source of truth, so is permissioned / authenticated. Been alot of heavy development since I'm building a 'BuildYourAgent' portal ontop that pretty much takes an openapi doc and turns it into an MCP server / hooks it up to an agent / gives you a CLI around it so it can integrate with all the crazy wild west approaches, while you know, still allowing us to maintain sanity and build servers that don't hallucinate and burn forests down.
Curious on thoughts! Bit of a rambling explanation. I hope the website does a better job! Lots of content helped with AI (I prefer speaking tech, but doesn't always transition well).
Also, looking for a potential cofounder to help balance that out! If your interested in potentially working together / adopting pikku feel free to leave a comment / ping me an email
[1] https://pikku.dev/