I've come to accept that I will delegate an ever-increasing amount of my work as a software engineer to LLMs. I was an early Claude Code superfan, and though my ego still tells me I can write better code situationally than Anthropic's proto-geniuses in a data center, these days I'm mostly making point edits and suggestions rather than writing modules by hand.

This shift has made me far more productive, but I've become increasingly uncomfortable with blindly turning over such a big part of my job to an opaque third party. While training my own model was out of the question for many obvious reasons (and model interpretability is an unsolved problem anyway), the agent harness and UX on top of it is just software, and software IS something I understand. So when I had some free time during my paternity leave, I took a stab at building some tooling to my own specifications.

I work at a startup called LangChain where we've been developing our own set of open-source agentic building blocks, and I settled on building an adapter between our Deep Agents framework and Agent Client Protocol (ACP). My goal was just to build a bespoke coding agent that fit my workflows, but the results were better than I expected. Over the past few months it's completely replaced Claude Code as my daily driver, with the added benefit of full observability into my agent's actions via LangSmith on top. In this post I'll cover how it works and how to set it up yourself!

Why an IDE + ACP Instead of a Terminal + TUI?

If you're not familiar with ACP, it's an open protocol that defines how a client (most often but not limited to IDEs like WebStorm or Zed) interacts with AI agents. It allows you to do cool things like quickly pass a coding agent the exact context you're looking at in an IDE.

I've gotten quite used to being productive in IDEs over my decade writing software professionally, and still find them valuable for a few reasons:

• I do still edit code by hand occasionally. Most often there are small edits I can make faster than explaining the problem to an agent, or because I can do something in parallel alongside a running agent like adding debug statements, but this still provides some alpha.

• IDEs are fantastic interfaces for viewing code in context. I most often use this to understand the general scope of a problem before prompting, or to self-review my current branch, but it's also often just faster for me to point the agent at a file rather than asking it to grep around.

I previously used Claude Code in a separate terminal pane in an IDE, which worked but always felt like two disconnected tools. In JetBrains IDEs, the agent lives in a native tool window with tight integration. I can @mention the file or block of code I'm currently looking at, and many of my threads are littered with messages like "Take a look at this. Does it look funny? @thisFile".

How it Works

The Agent

Though I could have created the various pieces for my agent from scratch, Deep Agents provided a good, opinionated starting point providing the following:

• Tools around interacting with the filesystem (read/write/edit_file, ls, grep, etc.)

• Shell access, which allows the agent to run verifications like lint, tests, and more

  • Alongside this, human-in-the-loop support to allow restricting dangerous actions

• A write_todos tool, which encourages the agent to take a planning step that breaks work into steps and tracks progress

  • In practice this makes a big difference on longer refactors to keep the agent focused

• Capabilities around spawning isolated sub-agents for parallel or compartmentalized work

  • Each one gets its own context, runs independently, and reports back, keeping the model's context window manageable

• Other important UX features like streaming, cancellation, prompt caching, context summarization

I also added some custom middleware that appends information about the current project setup in the system prompt, such as the current directory open in the IDE, whether a git repo was present, package manager detection, and more.

It's also possible to add skills, tweak the system prompt, add custom tools or MCPs, and more directly in Python rather than as a config option of a CLI.

The ACP Adapter

After deciding on a basic agent setup, I needed to hook that agent into the client via ACP. I created an adapter that implements the ACP protocol interface and handles session lifecycle, message routing, model switching, and streaming.

One nice surprise was how cleanly the agent’s capabilities mapped onto ACP concepts.

For example:

• The agent’s planning step (write_todos) maps naturally to agent plans in ACP

• Interrupts from the agent (e.g. “I want to run this command”) map to permission requests

• Threads and session persistence were nearly 1:1 with Deep Agents checkpointers

This meant I didn’t need to invent much glue logic - the protocol already had good primitives for most of what I wanted. The overall agent runner looks roughly like this, minus tool call and message formatting:

current_state = None
user_decisions = []
while current_state is None or current_state.interrupts:
    # Check for cancellation
    if self._cancelled:
        self._cancelled = False  # Reset for next prompt
        return PromptResponse(stop_reason="cancelled")

    async for stream_chunk in agent.astream(
        Command(resume={"decisions": user_decisions})
        if user_decisions
        else {"messages": [{"role": "user", "content": content_blocks}]},
        config=config,
        stream_mode=["messages", "updates"],
        subgraphs=True,
    ):
        if stream_chunk.__interrupt__:
            # If Deep Agents interrupts, request next actions from
            # the client via ACP's session/request_permission method
            user_decisions = await self._handle_interrupts(
                current_state=current_state,
                session_id=session_id,
            )
            # Break out of the current Deep Agent stream. The while
            # loop above resumes it with the user decisions
            # returned from the session/request_permission method
            break

        # ...translate LangGraph output into ACP
        # Tools that do not require interrupts are called
        # internally results are just streamed back here as well

        # current_state will be none when the agent has finished
        current_state = await agent.aget_state(config)

return PromptResponse(stop_reason="end_turn")

The human-in-the-loop flow was where I spent the most time. When the agent wants to run a shell command or make a file edit that requires approval, the adapter intercepts the interrupt from Deep Agents, and depending on what permissions mode the user has selected and what they have previously approved, either resumes immediately or sends a permission request to the IDE with options to approve, reject, or always-allow that command type.

The always-allow is session-scoped - if you approve uv sync once and choose "always allow", subsequent uv sync calls skip the prompt automatically, but I made efforts to prevent similar commands such as uv run script.py from bypassing the permission check.

Here's how the end result looks in WebStorm:

How it Went

While I haven't run formal evals, I was pleasantly surprised by how well my agent performed after only a few iterations. I didn't actually expect to switch off of Claude Code, and it was a great dogfooding exercise as well, since our OSS team was able to upstream some of my feedback back into Deep Agents itself.

My original goal of regaining code-level, rather than config-level, control over my daily workflows has also been great. When Anthropic had an outage a few weeks ago, I was able to switch over to OpenAI’s gpt-5.4 without skipping a beat, and I even found that it had some interesting quirks. I switch back and forth between models mid-session to gain different perspectives from each model when working on tricky tasks, and have also found open-source models like GLM-5 are quite capable while offering significant cost savings.

Another boon is observability via LangSmith tracing, which allows me to debug and improve my agent when I run into issues. Being able to see exactly what context was passed to the model, which tools it called, and where it went sideways helped me understand behaviors that were previously hidden inside the harness. Here's an example of what such a trace looks like:

For example, when I noticed that my agent was starting to take wide, slow sweeps of my filesystem, I used a trace to find a bug in my system prompt that told the agent the project was at the filesystem root rather than the current working directory.

Taking Back Your Dev Workflows for Fun and Profit

What started as a small late-night project I worked on around taking care of a newborn daughter turned into a huge success both for my own understanding of agent behavior and for improving my daily workflow.

It proved to me that Claude Code isn't magic but a bundle of very clever tricks rolled up into a neat package. The harness layer is just software, and software is something any developer can shape to fit how they want to work.

If you’re curious, I’d highly recommend trying an experiment like this yourself. Even a small prototype can teach you a lot about how these systems think and where they break. Clone the repo and follow the setup guide here to get started from source code. I'd love to know what you think - you can reach out to me on X @Hacubu!

Special thanks to @veryboldbagel and @masondrxy for helping productionize the adapter and dealing with my unending questions and feedback!

• The gap in raw reasoning capability between the best OSS models (DeepSeek, Qwen) and the best models from frontier labs has continued to shrink.

• OSS models now support key usability features such as function calling and structured output.

• Thanks to tools such as Ollama and the proliferation of GPUs in consumer laptops, more people than ever can discover and run models on their own hardware.

This continued trend means that even distilled versions of the best OSS models will become “good enough” for an increasing percentage of tasks. However, when it comes time to do something like serve an app to actual users, there’s a missing piece in this AI-hacker fairytale - how do I easily deploy a model on infrastructure I control?

When I saw that Google recently brought serverless GPUs into GA, it piqued my interest, and I was able to adapt one of their examples to support API key auth and make it fully OpenAI and LangChain-compatible. I wrote up a small guide here + a GitHub repo you can use to deploy your own!

Once live, your endpoint can be used as a drop-in substitute for clients and code that use these interfaces. It also requires no infrastructure management and scales down to zero instances when not in use.

You can serve any open source model from Ollama's registry in theory, including DeepSeek, Gemma, and Qwen, though in practice caps on Cloud Run resources will limit effective model size. For more on this, see the below section on model customization.

Let’s dive in!

Quickstart

Setting up Google Cloud resources

The initial setup for this project is the same as the official Cloud Run guide here.

If you don't already have a Google Cloud account, you will first need to sign up.

Navigate to the Google Cloud project selector and select or create a Google Cloud project. You will need to enabled billing for the project, since GPUs are currently not part of Google Cloud's free tier.

Next, you must enable access to Artifact Registry, Cloud Build, Cloud Run, and Cloud Storage APIs for your project. Click here, select your newly created project, then follow the instructions to do so.

GPUs are not part of the default project quota, so you will need to submit a quota increase request. From this page, select your project, then filter by Total Nvidia L4 GPU allocation without zonal redundancy, per project per region in the search bar. Find your desired region (Google currently recommends europe-west1, note that pricing may vary depending on region), then click the side menu and press Edit quota:

Enter a value (e.g. 5), and submit a request. Google claims that increase requests may take a few days to process, but you may receive an approval email almost immediately in practice.

Finally, you will need to set up proper IAM permissions for your project. Navigate to this page and select your project, then press Grant Access. In the resulting modal, paste the following permissions into the filter window and add them one by one to a principal on your project:

• roles/artifactregistry.admin

• roles/cloudbuild.builds.editor

• roles/run.admin

• roles/resourcemanager.projectIamAdmin

• roles/iam.serviceAccountUser

• roles/serviceusage.serviceUsageConsumer

• roles/storage.admin

By the end, your screen should look something like this:

Deploying your endpoint

Now, clone this repo and switch your working directory to be the cloned folder:

git clone https://github.com/jacoblee93/personallm.git
cd personallm

The repo extends Google’s official guide a lightweight proxy server, which runs in the Cloud Run instance. This proxy handles auth and forwards requests to a concurrently running Ollama instance.

Rename the .env.example file to .env. Run something similar to the following command to randomly generate an API key:

openssl rand -base64 32

Paste this value into the API_KEYS field. You can provide multiple API keys by comma separating them here, so make sure that none of your key values contain commas.

Install and initialize the gcloud CLI if you haven't already by following these instructions. If you already have the CLI installed, you may need to run gcloud components update to make sure you are on the latest CLI version.

Next, set your gcloud CLI project to be your project name:

gcloud config set project YOUR_PROJECT_NAME

And set the region to be the same one as where you requested GPU quota:

gcloud config set run/region YOUR_REGION

Finally, run the following command to deploy your new inference endpoint!

gcloud run deploy personallm \
  --source . \
  --concurrency 4 \
  --cpu 8 \
  --set-env-vars OLLAMA_NUM_PARALLEL=4 \
  --gpu 1 \
  --gpu-type nvidia-l4 \
  --max-instances 1 \
  --memory 32Gi \
  --no-cpu-throttling \
  --no-gpu-zonal-redundancy \
  --timeout=600

When prompted with something like Allow unauthenticated invocations to [personallm] (y/N)?, you should respond with y. The internal proxy will handle authentication, and we want our endpoint to be reachable from anywhere for ease of use.

Note that deployments are quite slow since model weights are bundled directly into the Dockerfile - expect this step to take upwards of 20 minutes. Once it finishes, your terminal should print a Service URL, and that's it! You now have a personal, private LLM inference endpoint!

Trying it out

You can call your endpoint in a similar way to how you'd call an OpenAI model, only using your generated API key and your provisioned endpoint. Here are some examples:

OpenAI Python SDK

uv add openai

from openai import OpenAI

# Note the /v1 suffix
client = OpenAI(
    base_url="https://YOUR_SERVICE_URL/v1",
    api_key="YOUR_API_KEY",
)

response = client.chat.completions.create(
    model="qwen3:14b",
    messages=[
      {"role": "user", "content": "What is 2 + 2?"}
    ]
)

See OpenAI's SDK docs for examples of advanced features such as function/tool calling.

LangChain

uv add langchain-ollama

from langchain_ollama import ChatOllama

model = ChatOllama(
    model="qwen3:14b",
    base_url="https://YOUR_SERVICE_URL",
    client_kwargs={
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
)

response = model.invoke("What is 2 + 2?")

See LangChain's docs for examples of advanced features such as function/tool calling.

OpenAI JS SDK

npm install openai

import OpenAI from "openai";

// Note the /v1 suffix
const client = new OpenAI({
  baseURL: "https://YOUR_SERVICE_URL/v1",
  apiKey: "YOUR_API_KEY",
});

const result = await client.chat.completions.create({
  model: "qwen3:14b",
  messages: [{ role: "user", content: "What is 2 + 2?" }],
});

See OpenAI's SDK docs for examples of advanced features such as function/tool calling.

LangChain.js

npm install @langchain/ollama @langchain/core

import { ChatOllama } from "@langchain/ollama";

const model = new ChatOllama({
  model: "qwen3:14b",
  baseUrl: "https://YOUR_SERVICE_URL",
  headers: {
    Authorization: "Bearer YOUR_API_KEY",
  },
});
const result = await model.invoke("What is 2 + 2?");

See LangChain's docs for examples of advanced features such as function/tool calling.

Latency

Keep in mind that there will be additional cold start latency if the endpoint has not been used in some time.

Model customization

The base configuration in this repo serves a 14 billion parameter model (Qwen 3) clocked at ~20-25 output tokens per second. This model is quite capable and also supports function/tool calling, which makes it more useful when building agentic flows, but if speed becomes a concern you might try smaller models such as Google's 4 billion parameter Gemma 3. You can also run the popular DeepSeek-R1 if you do not need tool calling.

To customize the served model, open your Dockerfile and modify the ENV MODEL qwen3:14b line to be a different model from Ollama's registry:

# Store the model weights in the container image
# ENV MODEL gemma3:4b
# ENV MODEL deepseek-r1:14b
ENV MODEL qwen3:14b

Note that you will also have to change your clientside code to specify the new model as a parameter.

🙏 Thank you!

This GitHub repo contains the source code for this guide.

If you have any questions or comments, please open an issue there. You can also follow me @Hacubu on X (formerly Twitter).

Over the past few months, I had the opportunity to do some cool exploratory work for a client that integrated LLMs like GPT-4 and Claude into their internal workflow, rather than exposing them through a chat interface. The general idea was to take some input data, analyze it using an LLM, enrich the LLM's output using existing data sources, and then sanity check it using both traditional tools and LLMs. This process could repeat several times until finally storing a final result in a database. I've been thinking of it as a pipeline that mixes LLMs with more mundane APIs where the output of one step feeds directly into the next.

The Problem

While building such pipelines, I quickly realized that while natural language is an excellent interface for a chatbot, it's quite a difficult one to use with existing APIs.

To illustrate this, let's say you wanted to generate and store a list of countries in Airtable. Naively asking an LLM Give me a list of 5 countries results in a numbered list of countries:

'1. United States\n' +
'2. Canada\n' +
'3. United Kingdom\n' +
'4. Australia\n' +
'5. Japan'

There are a few problems here - while the above output happens to be a numbered list, there is no guarantee of that. Also, you would need to write some awkward custom string parsing logic to extract the data for use in the next step of the pipeline.

The solution is to prompt the LLM to output data in some structured format, but it's not quite that simple. For example, asking, Give me a list of 5 countries, formatted as Airtable records might result in something like this:

'Airtable records require a unique ID and field values in a JSON format. Here is a list of 5 countries formatted as Airtable records:\n' +
'\n' +
'1. {\n' +
'  "id": "rec1",\n' +
'  "fields": {\n' +
'    "Country": "United States",\n' +
'    "Continent": "North America"\n' +
'  }\n' +
'}\n' +
'2. {\n' +
'  "id": "rec2",\n' +
'  "fields": {\n' +
'    "Country": "Canada",\n' +
'    "Continent": "North America"\n' +
'  }\n' +
'}\n' +
...

Though the LLM (in this case GPT-4) impressively knows the general schema of an Airtable record, this is even worse than the original attempt. There is conversational text at the top that must be parsed out, and the output format is still a numbered list. Additionally, the LLM has assumed the field names of your Airtable schema, which likely do not match your internal definitions.

I experimented with a few custom prompting strategies like Output only an array of JSON objects containing X, Y, and Z, but adding such language to all my prompts quickly became tedious. Furthermore, this was somewhat unreliable due to the non-deterministic nature of LLMs, particularly with long, complex prompts and higher temperatures.

The Solution

I had already been using LangChainJS, an open-source framework that helps with building complex applications around LLMs, for various pieces of the project. After asking around their Discord community, I discovered an elegant, built-in solution: output fixing parsers!

Output fixing parsers contain two components:

1. An easy, consistent way of generating output formatting instructions (using a popular TypeScript validation framework, Zod).

2. An LLM-powered recovery mechanism for handling badly formatted outputs using a more focused prompt.

You could use one to solve the earlier problem like this (note that you will need to run yarn add langchain and yarn add zod if they aren't already in your dependencies):

import { z } from "zod";
import { ChatOpenAI } from "langchain/chat_models/openai";
import { PromptTemplate } from "langchain/prompts";
import { LLMChain } from "langchain/chains";
import {
  StructuredOutputParser,
  OutputFixingParser
} from "langchain/output_parsers";

const outputParser = StructuredOutputParser.fromZodSchema(
  z.array(
    z.object({
      fields: z.object({
        Name: z.string().describe("The name of the country"),
        Capital: z.string().describe("The country's capital")
      })
    })
  ).describe("An array of Airtable records, each representing a country")
);

const chatModel = new ChatOpenAI({
  openAIApiKey: "YOUR_KEY_HERE", // Or set process.env.OPENAI_API_KEY
  modelName: "gpt-4", // Or gpt-3.5-turbo
  temperature: 0 // For best results with the output fixing parser
});

const outputFixingParser = OutputFixingParser.fromLLM(
  chatModel,
  outputParser
);

const prompt = new PromptTemplate({
  template: `Answer the user's question as best you can:\n{format_instructions}\n{query}`,
  inputVariables: ['query'],
  partialVariables: {
    format_instructions: outputFixingParser.getFormatInstructions()
  }
});

// For those unfamiliar with LangChain, a class used to call LLMs
const answerFormattingChain = new LLMChain({
  llm: chatModel,
  prompt: prompt,
  outputKey: "records", // For readability - otherwise the chain output will default to a property named "text"
  outputParser: outputFixingParser
});

const result = await answerFormattingChain.call({
  query: "List 5 countries."
});

console.log(JSON.stringify(result.records, null, 2));

Clean and readable! And here's an example of what the results look like:

[
  {
    "fields": {
      "Name": "United States",
      "Capital": "Washington, D.C."
    }
  },
  {
    "fields": {
      "Name": "Canada",
      "Capital": "Ottawa"
    }
  },
  {
    "fields": {
      "Name": "Germany",
      "Capital": "Berlin"
    }
  },
  {
    "fields": {
      "Name": "Japan",
      "Capital": "Tokyo"
    }
  },
  {
    "fields": {
      "Name": "Australia",
      "Capital": "Canberra"
    }
  }
]

Success! The result will already be typed as an array of objects, so there's no need for JSON.parse() calls or any further parsing.

Note that the output fixing parser will throw an error if, for whatever reason, it can't generate an output matching the provided Zod schema. You could even pipe it directly into an Airtable API call!

Additional Tips

• Descriptions provided with .describe() are optional, but give the LLM helpful context when populating individual fields. The LLM will also use clues like the field name and the overall structure of the provided schema.

  • If you're struggling to generate output in the right format, adding descriptions or tweaking the language in these descriptions can help.

• You can use different model instances in the output fixing parser and whatever chain you're using, allowing you to mix and match temperatures and even providers for best results.

Thanks for Reading!

I hope this post helps you better use the power of LLMs in your projects!

I've actually enjoyed building with LLMs and specifically LangChain so much that I recently joined their team, so expect to see more related content over the coming months! And if you have any questions or have ideas for what you'd like me to write about next, please leave a comment or reach out to me on Twitter @Hacubu. I'll be active in the JS channels of LangChain's community Discord server as well.

Happy prompting!

So why did I decide to become a freelance developer? After making the decision to leave Autocode and looking back at my time there, I realized I was quite interested in seeing how other organizations function - how they're structured and managed, the problems they're solving (both technical and non-technical!), and how they overcome adversity. I also wanted to explore different product areas and meet interesting, passionate people. Freelancing ticked those boxes, and had the added benefit of flexibility and control over my schedule after years of constant late-night product launches and long on-call stretches.

It sounded great in theory, but I quickly found that getting started was more complex than just finding a client, writing some code, and cashing a check.

My first thought was to simply Google how to start consulting. Here's what I saw:

The results included pages of clickbait-y, generic content marketing articles published by companies looking for SEO, as well as an intimidating dropdown that said I should expect getting started to cost $10k-50k (it's much, much less!). The actual details of getting started as a freelancer - like how to incorporate, tax implications, how to set up a contract - proved scarce. And that's really too bad, since freelancing opens up opportunities for both full-time work and side-hustles.

Here's how I cut through all the noise, incorporated my business, and onboarded my first paying client!

Sidebar: I am not a lawyer or an accountant - don't take my experience as gospel and do your own research!

Deciding on a Corporate Structure

Confused by all the information online, I asked my cousin, who had done some freelancing in the past, for some advice on corporate structure. She replied, "Oh, you can just start out by using your Social Security Number!"

Wait, really? Sure, otherwise every part-time Uber and Lyft driver would need to incorporate! This seemed like the easiest approach, but I decided on an LLC for a few reasons (in no specific order of importance):

1. The corporation is treated as a separate entity from me. In an unlikely scenario where a client sues, my liability is limited in most cases (as the name Limited Liability Corporation implies!). I probably won't lose my house.

2. It gives the impression of professionalism to clients.

3. I thought it'd be cool.

There are more complicated structures as well, but since the business would just be me an LLC seemed like a good balance between ease of management and legal protection in the worst case. Single-member LLCs can also report income on the owner's tax return, so I still only need to file one tax return.

Incorporating an LLC

Note that your experience may vary depending on the state - I filed in California.

After deciding on an LLC, my next step was legally incorporating. As a California resident, I was unsure of the tax implications if I incorporated in a different state, so I chose to incorporate in California. The downside to this is that California has a very expensive Annual Tax on LLCs - $800 even if you make no money, and an additional tax if you make more than $250,000 a year!

The good news is that the $800 component of the first year tax is being waived for businesses that incorporate before January 1st, 2024.

Side note: I probably made a mistake here - I forgot about Stripe Atlas! They charge $500 to incorporate a business in Delaware (which has the most business-friendly laws for some reason), and $100 a year for management after. It's a bargain compared to fees in California, especially since they give Stripe credits that you can use to avoid payment processing fees when invoicing clients! There's a good chance I'll spin down my current LLC before the $800 tax kicks in and redo things in Delaware.

This process is run by the California Secretary of State's office. They have a surprisingly decent website, and all the filing can be done online.

There's a section where it'll asked if I was a professional service provider, but this only applies to professions that require a license, and writing software does not (yay?). The process required information like my Social Security Number, a business name, and a business address (like most freelancers, I don't have an office, so I used my current home address) and pay a small fee. A few days later my application was accepted, I had my Articles of Incorporation, and Remora Software, LLC was born!

After incorporation, I had to file a "Statement of Information" within 90 days of incorporation. You can do this from the Secretary of State's website, and it's required every two years afterward.

Opening a Business Checking Account

In software, there's a very important design concept called separation of concerns. it turns out, the same applies to LLCs. It becomes much easier to maintain a company's separate personhood and liability protection if all business income and expenses are separated from personal ones, so this is a must.

Plus, you'll feel like a boss when the bank sends a card with your company name on it.

Opening a business bank account requires an EIN (employer identification number). The IRS assigns EINs, and again, I was pleasantly surprised with how easy the process was. Everything is online, and I had an EIN a few minutes after applying using information from my LLC's Articles of Incorporation.

You can then transfer money from your business account to your personal account via owner's draw as often as you'd like - your checking account will act as a record of how much revenue your business is making for tax purposes.

I opened an account with Chase as I had used them in the past and they were running a $700 promotion for new accounts that meet certain requirements, but there are plenty of good options out there.

Setting Up a Contract

I was fortunate enough to be referred to a small startup interested in hiring someone with my skills. In retrospect, I could have negotiated a much higher rate, but I was eager to get my first client and get a win on the board.

The next step was putting together a contract and figuring out how to get paid. I looked around for solutions and eventually found Honeybook, a client management platform. The week-long free trial and $1/month introductory rate drew me in, and I found it well-suited for my needs.

I used Honeybook's provided standard contract template, which I trusted because they've raised almost half a billion dollars. It conveniently included an invoicing page, payment processing, and automatic reminders. They charge a 1.5% fee for ACH transfers, so I may explore using Stripe, a wire transfer, or Zelle in the future, but all in all, it was a convenient and client-friendly way to get paid, though there was some difficulty verifying my payout account because I had only incorporated a few days before.

The initial contract was for two weeks, and I structured payment so that half of the value was due up front and half at the end of the contract. The client signed and sent the money, I got to work, and it was a great feeling to have my first freelance contract in the books!

Thank You!

If you've made it this far, thanks for reading! I'm not sure I'll remain a full-time freelancer forever, but incorporating was an extremely rewarding experience and opens up the potential to do part-time consulting on the side. I'd encourage more developers to give it a shot! And please let me know in the comments if anything in the article looks amiss.

If you're interested in hiring me, you can read more about me on my personal website - I specialize in cloud architecture/systems design, devops, and backend development, but started my career as a frontend engineer on Google Photos and can contribute to any part of a stack.

To stay up to date with my journey, follow me here or on Twitter @Hacubu. Happy hacking!