Joeckel Design did not begin with a business plan, a service catalog, or a clear idea of what it would eventually become. It grew from an early interest in technology and the discovery, years before I had a company, that code could turn an idea into something useful in the real world.
For a long time, freelancing was inconsistent. Some years brought interesting projects and momentum. Other years were quiet while my career moved through full-time engineering roles, contracts, leadership, and product work. It was less a straight line than a thread I kept picking back up.
That thread eventually became a company.
The biggest shift was not from websites to AI. It was learning that a client is rarely asking for software. They are asking for a better way to run part of their business.
It did not start as a company
My interest in building with technology started before websites. In middle school, I took a class that introduced me to CNC programming. It gave me an early look at how a set of instructions could control a process and produce a physical result. That connection between code and something tangible stayed with me.
By high school, that curiosity led me to sign up for a web design and development class. Instead of using code to direct a machine, I could use it to create something that anyone with a browser could see. The class gave me a place to start, and it led to the first website I put into the world: a site for my friend’s mom’s bar.
I cannot place the exact year with confidence. What stayed with me was not only the struggle of getting the website online. It was realizing that what I built had to be suitable for a real establishment. This was no longer a class exercise where the technical result was enough. The site would represent someone else’s business to actual customers.
Even though the stakeholder was my best friend’s mom, she was still a stakeholder. I had to listen to how she described the bar, understand what she wanted the website to communicate, and translate that into decisions about the content, structure, and design. I had to show her what I was building, hear what did not feel right to her, and revise it. My personal preference was not automatically the right answer if it did not represent her business or give its customers a useful experience.
I did not have language like discovery, requirements, or review cycles yet, but I was beginning to do all three. That relationship made the work a product rather than an assignment. It also made the responsibility of deploying it feel much more real.
Building the pages was one problem. Deploying them introduced an entirely different vocabulary: domains, hosting accounts, nameservers, FTP credentials, server folders, and file permissions. Something could work perfectly on my computer and then fail after I uploaded it, often without an error message that made any sense to me. There was no preview environment or automated pipeline. The live website was the test environment, and every fix meant changing the thing people could actually see.
Eventually, the site loaded from a real domain. It was a modest website for a local bar, but seeing it online changed the scale of the work for me. I was no longer just making pages on a computer. I was responsible for putting something into the world and keeping it there.
My earliest freelance work grew from there: a website here, a redesign there, and plenty of uncertainty about where the next project might come from.
At that point, I understood that a website had to serve someone beyond me, but I still thought the value was mostly in making the thing. A client needed pages, so I built pages. They needed a form, so I built a form. Success meant getting the design right, making it work, and publishing it.
The longer I worked with clients, the more I saw what was happening underneath the request. A request for a “website” might really be a request to make the company look credible. A request for a “dashboard” might be an attempt to replace a process spread across email, paper, folders, and people’s memories.
That distinction changed how I approached the work. I stopped listening only for features and started listening for friction.
The project that changed what “a website” meant
One of the projects that expanded my idea of client work was for a company involved in pressure testing at oil drilling sites.
They did not need a marketing site. They needed a working system.
Their customers needed a place to access receipts and project documents, then download those records when they were needed. The dashboard had to turn a scattered administrative process into something organized and available to the client.
On paper, a document portal sounds simple. Give someone a login, show them a list of files, and add a download button. In practice, it forces a much broader set of questions:
- How should information be organized so a customer can find it later?
- Which records belong to which client?
- What should be easy for the internal team to upload and maintain?
- What does the customer need to understand without calling someone for help?
- How do you make a system feel dependable when it holds business records?
The visible interface was only the edge of the project. Behind it were data structures, access rules, file storage, and the operational reality of the people using it.
This was also my first experience building a multitenant application. The dashboard needed a login and multiple user accounts, but the deeper requirement was isolation. After signing in, each client had to enter their own part of the application and see only the receipts and documents that belonged to them.
It taught me the difference between authentication and authorization in a way a tutorial never could. Knowing who had logged in was only the beginning; the data model, queries, and file access all had to preserve the boundary between customers.
Security had to be considered throughout the application, not treated as a feature that ended at the login screen. Every path to a receipt or document had to account for who was making the request, which client they belonged to, and whether that record belonged to the same client. One customer seeing another customer’s data was an unacceptable failure, so tenant isolation had to shape the system from the database through the interface.
The real promise was not simply that users could sign in. It was that the system would show them the correct information and protect everything else.
The application ran on Heroku with a MySQL database provisioned through the platform. Heroku made deploying the application feel substantially more modern than uploading files to shared hosting, but the MySQL experience felt archaic even then. The application layer had moved forward while working with the database still carried the friction of an older hosting model.
That contrast became part of the lesson too. A platform can simplify one layer of a system without making the entire architecture modern. I still had to understand where the data lived, how the application connected to it, and what the limitations of that managed environment meant for a product people depended on.
That was an important lesson: full-stack development is not a collection of technologies. It is the ability to follow a real process from the person using the screen all the way down to the system responsible for keeping its promises.
Following an order through the business
Another project made that lesson even clearer.
A small e-commerce operation working across marketplaces such as Amazon and Etsy hired me to build an internal production tool. The software needed to follow an Etsy order from the moment it arrived, through production, and eventually into shipping. It pulled order information from Etsy and connected the workflow to shipping partners including UPS, FedEx, and others.
This was not a storefront. Customers would never see most of it. It was software for the people doing the work.
At the time, Etsy’s API did not provide the data the company needed for production. There was no clean endpoint I could call to populate the internal workflow, so I had to retrieve the information from the same account pages the team used themselves.
I built a web scraper in Python with Selenium. It could open Etsy, log in to the company’s account, navigate to the orders page, and extract the data the production team needed. That sounds straightforward when reduced to a sentence. In practice, Etsy authentication alone made it difficult. The scraper had to operate as an authenticated browser session and move through a website designed for a person, not for another system.
Unlike an API, a webpage does not promise that its structure will remain stable for an integration. A change to the login flow, page layout, loading behavior, or markup could interrupt the entire path to the order data. Building the scraper required me to think not only about the successful path, but also about all the ways browser automation could fail before the production tool ever received an order.
To turn that scraper into something the business could depend on, I repurposed a Mac mini as an on-site server. It ran the scraping program at a set time each night and stored the collected order data in the system. The job had to operate without me standing over it, turning a browser automation script into a scheduled part of the company’s production infrastructure.
I also built a desktop control application in Python with Tkinter to manage the scraper’s state. It provided a local interface for operating the automation rather than requiring someone to manage the process through code or a terminal. Once the nightly data was imported, a React.js web application became the working interface where the team processed orders and moved them through production.
The React interface and its MySQL database were hosted in AWS, making this project my first exposure to the platform. The Mac mini remained on-site and fed the scraped order data into that hosted system. The architecture was hybrid before I had much reason to use that word: local hardware handled the browser automation while AWS held the web application and production data.
The complete system crossed several boundaries: on-site hardware, a scheduled Python process, Selenium browser automation, a Tkinter desktop interface, an AWS-hosted MySQL database, and a React web application. It was a practical full-stack architecture shaped around the tools, constraints, and people already inside the business.
An order was not just an order number. It moved through a sequence of real steps. Someone had to know what had been purchased, what needed to be produced, where it was in that process, and when it was ready to leave the building. Then the system had to hand that work off to external carrier services without losing the thread.
Building that kind of tool teaches you to respect edge cases. APIs fail. Statuses do not always line up neatly between systems. A process that sounds linear in a meeting often has exceptions the team handles so naturally that nobody thinks to mention them.
It also teaches you how much knowledge lives with the client.
My job was not to arrive with a predetermined workflow and force the company into it. My job was to understand how the business actually moved, identify where software could remove friction, and build something the team could trust enough to use every day.
Learning to work with clients, not around them
Those projects helped me understand that client work is a discipline of translation.
Clients know their businesses. Engineers know how to turn behavior into systems. The best work happens when neither side treats the other as an order taker.
I had to learn how to ask better questions, explain tradeoffs without hiding behind technical language, and show unfinished work early enough for feedback to matter. I had to learn that the first description of a problem is rarely the complete description, and that changing course after learning something is not failure.
There were growing pains. Estimates were not always right. Requirements changed. A “small” integration exposed a much larger workflow. Sometimes the most technically interesting option was not the right option for the client’s budget or team.
Over time, I became less interested in proving how much technology I could use and more interested in choosing the smallest dependable system that solved the whole problem.
That idea now sits at the center of Joeckel Design.
The hosting stack kept moving
The work changed, but so did the ground underneath it.
That early bar website was my introduction to the fact that deployment was its own engineering problem. For years, getting work online meant cPanel, shared hosting, and FTP. You configured a domain, uploaded files, checked the live site, and hoped the server environment behaved the way it did locally. A release could depend on file permissions, a runtime version, a DNS record, or whether the latest folder actually made it to the right place.
There was very little distance between “publishing” and “changing production.”
That taught me to respect backups, configuration, and the parts of a project that nobody sees until they break. It also taught me that hosting is part of the product. A beautiful application that cannot be deployed reliably is unfinished.
Heroku became an important bridge between that shared-hosting era and the cloud systems I use today. Instead of treating a server like a folder I had to maintain by hand, I could push an application to a platform designed to run it. That was a major improvement. But the pressure-testing dashboard also exposed how uneven that transition could be: application deployment felt modern while its MySQL service felt rooted in the previous generation of hosting.
The e-commerce production system was the next step and my first experience with AWS. Its React interface and MySQL database lived in AWS while the Mac mini scraper ran inside the client’s business. That arrangement expanded my idea of cloud architecture: a product did not have to live entirely in one environment, but every part still had to exchange data reliably and support one continuous workflow.
Cloud services improved a lot of this, but they did not remove complexity. They moved it.
Today, Joeckel Design uses GitHub Actions, Azure Static Web Apps, Azure Functions, Container Apps Jobs, Table Storage, and automated deployment pipelines. A push can build, validate, and publish a site without someone dragging files into a server.
That is better—but “automated” does not mean “automatic.”
The failure modes now live in identities, secrets, CORS policies, job schedules, build environments, usage limits, and service boundaries. A deployment mistake can still take production down; the cloud can simply help you make that mistake faster and at a larger scale.
Learning this new layer has involved the same cycle as everything before it: build, observe, break something, understand why, improve the system, and document the lesson so the next release is safer.
Turning freelance experience into a company
For years, Joeckel Design was essentially a name around whatever freelance opportunity appeared next. The work was real, but the business was reactive.
The company it is becoming today is more intentional.
It still builds websites and custom applications, but the surrounding system has matured. The current operation includes a React-based agency site, an Astro pipeline for building focused client previews, automated deployment, lead and contact infrastructure, and tools for managing the work behind the work.
That internal investment matters. A company that builds operational software for clients should be willing to improve its own operations too.
The shift has also meant defining what Joeckel Design believes. One of those beliefs is that most businesses do not need more software for its own sake. They need a clear solution, a manageable cost, and a system they can understand.
That became especially important when AI entered the picture.
AI changed the tools, not the responsibility
Today, a growing part of the work is building AI-based answering services, website chat assistants, workflow automations, and custom tools for companies.
The demos can look magical. The engineering is still full-stack.
A useful AI assistant needs more than a model. It needs trusted source information, a clear system prompt, cost controls, rate limits, error handling, conversation storage, secure integrations, a human handoff, and an interface that tells people what the system can and cannot do.
The same is true for an answering or booking workflow. The model may understand the customer’s words, but ordinary software still needs to validate the request, check the schedule, store the result, send the notification, retry a failed service, and preserve a reliable record.
Joeckel Design’s approach is what I call right-sized AI: use the model where judgment or language is genuinely useful, then use deterministic code for everything that should be predictable.
That position came from experience, not theory.
At one point, I paused an automated site-building workflow because its AI cost was outrunning the revenue it could support. It was a technically exciting system and the wrong operating model at that moment.
That was a useful failure. It reinforced a lesson client work had been teaching me for years: the cleverest implementation is not automatically the best product.
What I am building now
The work today spans compelling user interfaces, backend services, data, cloud infrastructure, deployment, and AI implementation.
The interface still matters. It is where a person decides whether the system feels clear and trustworthy. But it is not the entire product. The experience is only as good as the APIs, data, integrations, and operational decisions supporting it.
That is the through line between an early client website, a document dashboard for a pressure-testing company, an Etsy-to-shipping production system, and an AI assistant answering questions on a business’s website.
Each one begins with someone trying to accomplish something.
Each one requires understanding what happens before and after the screen.
And each one asks the same fundamental question: what is the most useful system I can build for the way this business actually works?
Still becoming
Joeckel Design is more focused than it was twenty years ago, but I do not think of the company as finished.
The tools will keep changing. Hosting will change again. AI models will get cheaper, faster, and more specialized. Interfaces will move into places we do not yet consider screens.
The responsibility will stay familiar: listen closely, understand the real process, choose the right amount of technology, and build the entire path from idea to dependable product.
The company grew out of a freelance career that was often hit or miss. What made it durable was not a perfect sequence of wins. It was continuing to learn from the projects, the clients, the deployments, and the failures—and turning those lessons into a better way of building.
That is what Joeckel Design is now.
And it is still becoming.