Most serverless platforms are great when your function is small, stateless, and finishes quickly.

But modern AI applications often do not look like that.

They need to:

• run background jobs
• process files
• call LLMs
• execute multi-step pipelines
• expose API endpoints
• handle webhooks
• run scheduled tasks
• keep containers warm
• preserve logs and traces
• avoid Kubernetes complexity

That is the problem I am working on with Inquir Compute.

Inquir Compute is an AI-first Function-as-a-Service platform designed for developers who want to deploy functions, API endpoints, cron jobs, webhooks, and background workflows without managing Kubernetes, containers, ingress, scaling logic, or infrastructure boilerplate.

Why I started building it

I originally worked on Inquir as a search-as-a-service product.

The idea was simple: help developers build search engines over different data sources.

But while building ingestion pipelines, I noticed something interesting.

A lot of the hard parts were not just about search.

They were about compute.

For example:

• fetch data from external APIs
• normalize and enrich documents
• split content into chunks
• call AI models
• index the result
• retry failed steps
• run jobs on a schedule
• expose parts of the workflow through HTTP APIs

At some point, the ingestion pipeline itself became the most interesting part of the system.

That was the pivot.

Inquir Compute was born from the idea that AI applications need a simpler way to run server-side logic.

Not just short-lived functions.

But real workflows.

The problem with traditional serverless

AWS Lambda, Vercel Functions, Cloudflare Workers, and similar platforms are powerful.

But when you build AI-heavy systems, you quickly hit limitations.

Some common issues:

1. Timeouts

AI workflows are not always fast.

A function may need to:

• process a large document
• call multiple LLM APIs
• wait for an external service
• crawl a website
• transform data
• execute several dependent steps

Short execution limits become painful very quickly.

2. Cold starts

For many APIs, cold starts are acceptable.

For AI agents and interactive workflows, they are not always acceptable.

If a user is waiting for an agent to respond, container startup time matters.

3. Background jobs are awkward

A lot of platforms are optimized for request-response functions.

But real products need background work:

• send emails
• process uploads
• generate reports
• sync data
• update embeddings
• call webhooks
• clean old records
• run scheduled tasks

Developers often end up connecting several services together just to run a job reliably.

4. Kubernetes is too much for small teams

Kubernetes is powerful, but it is also a lot of operational overhead.

For many indie hackers, startups, and small engineering teams, the ideal experience is:

I write a function, deploy it, expose it as an API, schedule it, and see logs.

Not:

I configure deployments, services, ingress, secrets, volumes, autoscaling, observability, and routing manually.

What Inquir Compute does

Inquir Compute is a serverless compute platform focused on developer experience.

The core idea is simple:

Write backend logic as functions and run them as APIs, cron jobs, webhooks, background tasks, or pipeline steps.

A function can be used in different ways.

For example, the same function could be:

• exposed as an HTTP endpoint
• triggered by a cron schedule
• called inside a pipeline
• used as a webhook handler
• executed manually from the dashboard
• used by an AI agent

Example: a simple function

A function can be as simple as this:

export default async function handler(event) {
  const name = event.queryStringParameters?.name || "developer";

  return {
    statusCode: 200,
    body: {
      message: `Hello, ${name}!`,
    },
  };
}

Then it can be mapped to an API route like:

GET /hello

And called from the outside:

curl https://your-domain.com/api/gw/workspace/hello?name=Alex

The goal is to make deployment feel closer to writing application logic, not managing infrastructure.

API endpoints

Inquir Compute includes an API Gateway-like layer.

That means functions can be mapped to routes:

GET /users/:id
POST /webhooks/stripe
POST /agent/chat
GET /reports/:reportId

The function receives an event object similar to common serverless platforms:

export default async function handler(event) {
  const userId = event.pathParameters.id;

  return {
    statusCode: 200,
    body: {
      userId,
      message: "User profile loaded",
    },
  };
}

This makes it possible to build small APIs without setting up a traditional backend server.

Cron jobs

AI and data applications often need scheduled execution.

For example:

• run a daily sync
• update search indexes
• refresh cached data
• send scheduled reports
• check external APIs
• run cleanup jobs

With Inquir Compute, the goal is to make cron a first-class concept.

Example:

0 2 * * *

This could trigger a function every day at 2 AM.

export default async function handler() {
  console.log("Running nightly sync");

  // Fetch data
  // Transform it
  // Store it
  // Send report

  return {
    statusCode: 200,
    body: {
      ok: true,
    },
  };
}

Webhooks

Webhooks are another common use case.

You may want to receive events from:

• Stripe
• GitHub
• Telegram
• Slack
• Notion
• custom internal systems

Instead of running a full server just to receive webhook events, you can deploy a function:

export default async function handler(event) {
  const payload = JSON.parse(event.body);

  console.log("Webhook received:", payload);

  return {
    statusCode: 200,
    body: {
      received: true,
    },
  };
}

Then expose it as:

POST /webhooks/github

Pipelines

One of the most important concepts in Inquir Compute is the pipeline.

AI workflows are rarely a single function.

They are usually a chain of steps:

Fetch data
→ Clean data
→ Chunk content
→ Generate embeddings
→ Store result
→ Notify user

Or:

Receive user request
→ Call LLM
→ Search knowledge base
→ Call another tool
→ Generate response
→ Save trace

A pipeline can be sequential or parallel.

Some steps may depend on previous steps.

Some steps may need retries.

Some may have conditions.

The long-term goal is to make these workflows easy to build and observe.

Hot containers

A major design idea behind Inquir Compute is keeping containers warm.

Instead of always starting a new container for each invocation, Inquir Compute can keep function containers available for reuse.

This is especially useful for AI workloads where startup time can be expensive.

For example, a function may need to load:

• an SDK
• a model client
• configuration
• cached data
• dependencies
• initialization logic

Keeping containers warm can improve the developer and user experience.

Observability by default

Serverless is only useful if you can understand what happened.

For each function or pipeline run, you need visibility into:

• logs
• execution time
• errors
• input/output
• failed steps
• retries
• traces

Inquir Compute is designed with built-in observability so developers do not need to wire everything manually from day one.

Why not just use Kubernetes?

You can absolutely build something like this on Kubernetes.

In fact, under the hood, many platforms eventually need container orchestration concepts.

But most developers do not want to start there.

For many projects, Kubernetes is too low-level.

You need to think about:

• deployments
• services
• ingress
• autoscaling
• secrets
• namespaces
• persistent volumes
• container lifecycle
• monitoring
• networking

Inquir Compute tries to hide most of that behind a simpler abstraction:

Function → Route → Job → Pipeline → Logs

The developer should focus on application logic.

Who is it for?

Inquir Compute is mainly for developers building:

• AI agents
• internal tools
• SaaS backends
• data pipelines
• webhook-based systems
• scheduled jobs
• API endpoints
• automation workflows
• document processing systems
• search and RAG pipelines

It is especially useful when you want serverless simplicity but need more flexibility for long-running or background workloads.

Example use case: AI content pipeline

Imagine you want to build an AI content pipeline.

The workflow could look like this:

1. Read topic from database
2. Generate article outline
3. Generate draft
4. Improve SEO
5. Generate social post
6. Save result
7. Send notification

Each step can be a separate function.

export default async function generateOutline(event) {
  const { topic } = event.input;

  // Call LLM here

  return {
    outline: [
      "Introduction",
      "Problem",
      "Solution",
      "Example",
      "Conclusion",
    ],
  };
}

Then another function can generate the article.

Another one can create a LinkedIn post.

Another one can publish or schedule the result.

This is the kind of workflow that does not always fit well into classic request-response serverless functions.

The bigger vision

I think AI applications need a new kind of backend platform.

Not just hosting.

Not just functions.

Not just containers.

But a compute layer designed around:

• agents
• tools
• workflows
• long-running tasks
• scheduled jobs
• API routes
• observability
• developer experience

That is what I am trying to build with Inquir Compute.

Current status

Inquir Compute is still evolving, but the core direction is clear:

• deploy functions from the browser
• expose functions as API endpoints
• run background jobs
• run cron jobs
• build pipelines
• keep containers warm
• provide logs and traces
• reduce infrastructure overhead

The goal is not to replace every cloud platform.

The goal is to make it much easier to build and run AI-first backend logic.

Final thoughts

Serverless made backend deployment much simpler.

But AI applications are changing what backend workloads look like.

They are longer-running.

They are more stateful.

They depend on external APIs.

They need background execution.

They need orchestration.

They need visibility.

And they should not require every developer to become a Kubernetes expert.

That is why I am building Inquir Compute.

If you are building AI agents, automation workflows, data pipelines, or serverless backends, I would love to hear what problems you are running into.

In case you like it, I will share more insights on technical solutions I came up to.