For years, the idea of a citizen developer was tied closely to no-code and low-code.

The premise was simple: people who understood the business could build useful software without becoming traditional software developers. They could connect systems with Zapier, build lightweight apps with tools like Glide, create internal workflows, and solve problems that would otherwise have sat in an IT backlog.

That was already a meaningful shift, but I think the definition is changing again.

At ZapConnect this year, Zapier showed off a next-generation builder that can generate TypeScript, a programming language, while also representing an automation visually. Tools like Zite are taking a similar idea into application development: you describe what you want to build, and the platform generates the code needed to make it work.

The interesting part is that the person building the solution may never need to write, or even read, most of that code.

So are they still a citizen developer? I think so.

In fact, I think we're entering a new phase of citizen development where "no-code" is no longer the defining characteristic. What defines it now is that someone who understands a business problem can turn that understanding into working software without needing to be a traditional programmer.

The term has been around much longer than the current wave of generative AI.

Gartner is widely credited with popularizing the concept. Its definition has shifted over time, but the core idea has held: a citizen developer is someone outside a traditional IT development role who creates or extends technology capabilities for themselves or others.

That distinction matters. Citizen development was never really about avoiding code for its own sake. It was about moving the ability to create technology closer to the people who understood the problem.

No-code and low-code tools made that possible by abstracting away much of the technical complexity. Instead of writing API calls, you selected an app and an action. Instead of writing conditional logic, you created a path. Instead of building a database from scratch, you created a table. Instead of deploying a web application, you published an interface.

For a generation of builders, tools like Zapier became a visual programming language.

A traditional developer might tell a computer exactly how to accomplish something using a programming language. A no-code builder might configure the same logic using visual components. Increasingly, a citizen developer can simply describe what should happen, and the system can generate the implementation.

Zapier's next-generation builder, announced at ZapConnect this year as Next Gen Zaps, is a useful example.

It isn't simply generating a prettier Zap. It can generate TypeScript underneath the workflow, and that opens up things that have historically been difficult, or sometimes impossible, to express in a purely visual builder: combining branches back together, continuing execution after loops, supporting multiple triggers, and building more sophisticated logic.

The user may still be building through an accessible interface, but code is very much involved. What's changing is who's responsible for producing it. Increasingly, it's the platform.

This connects to a much larger conversation happening across software right now.

AI-assisted development has dramatically cut the cost and effort of producing code. That doesn't mean software engineering has become trivial, and it certainly doesn't mean every piece of software should be generated by prompting a model. But it does change where the scarce skill lives.

If producing the implementation becomes easier, more value moves upstream:

• What problem are we actually solving?
• What should happen when something goes wrong?
• Which system should own the data?
• What information needs to move between systems?
• Which exceptions matter?
• What should require human approval?
• What needs to be deterministic?
• How will we know whether the result is correct?

Those aren't primarily coding questions. They're systems-thinking and domain-expertise questions.

That's why I don't think the citizen developer of the future is necessarily the person who knows the most tools. It may be the person who understands the business deeply enough to describe what should exist, and who has enough technical literacy to guide, test, and improve what gets generated.

One of the more interesting sessions I attended at ZapConnect wasn't really about development at all. It was about hiring in the age of AI.

Zapier's talent team described an AI fluency rubric built around four areas: mindset, strategy, builder skills, and accountability and judgment. They also talked about learning agility, whether someone can learn hard things fast, because the tools people are using today may not be the tools they're using three months from now.

That resonated with me. I've hired for roles in the promo industry myself, and those are exactly the traits I've looked for. Knowing Zapier is useful. Knowing APIs is useful. Knowing how a loop works is useful. But those skills sit underneath more durable traits: curiosity, experimentation, judgment, an ability to understand systems, and a willingness to rethink how work gets done.

The panel also made the point that AI actually increases the importance of expertise and judgment. If a system can generate a large amount of work quickly, someone still needs to determine whether that work is any good. The future isn't just about being able to generate software. It's about being able to recognize good software, good automation, and good process design when you see it.

The panel's take on hiring backed this up: nonlinear career paths, the kind that might once have looked messy on a résumé, often show exactly the adaptability employers need now. The tools will change. The ability to learn, question, build, evaluate, and adapt is a lot more durable.

It's easy for every technology conversation right now to turn into an AI conversation, but AI doesn't need to be everywhere.

Zapier recently looked at how leading companies were actually using AI inside automated workflows. Even among strong adopters, AI accounted for only 18% of the steps in AI-powered workflows. The remaining 82% relied on conventional automation: rules, logic, app connections, and data movement. That's a useful reality check.

If a workflow needs to move a customer ID from one system to another, you probably don't need a language model. If it needs to determine whether an incoming email represents a sales opportunity, a customer complaint, or an invoice request, AI may be useful. One requires execution; the other requires interpretation. A capable citizen developer needs to know the difference, and to treat AI as another tool in the toolbox, not the toolbox itself.

Zapier's own Next Gen Zaps builder is built around this same idea, under a name they call fluid determinism: each step in a workflow can shift between AI reasoning and predictable if-then logic depending on what that step actually needs. The steps that just move data or apply a fixed rule stay deterministic, cheap and consistent. The steps that need to interpret something ambiguous get handed to the model. It's a useful way to think about where AI belongs in an automation, not as a layer poured over the whole workflow, but as a mode individual steps can switch into when the task calls for interpretation instead of execution.

There's an obvious tension in citizen development: if you make it easier for more people to create software, you also make it easier for more people to create badly governed software.

That doesn't mean organizations should lock everything down and send every automation request back through IT. That would eliminate much of the value citizen development creates. It means the role of IT changes. Instead of being the only group allowed to build, IT increasingly becomes responsible for establishing the environment in which everyone else can build safely: identity and access controls, role-based permissions, approved applications and connections, audit logs, version history, data-retention policies, testing standards, documentation, and ownership and continuity.

This was another theme running through ZapConnect and Zapier's broader enterprise strategy. Zapier's enterprise platform now includes controls for application access, user provisioning, role-based permissions, an expanded audit log, security policies, and centralized administration. That's not separate from the citizen-development story. It's what makes citizen development viable at larger scale.

The goal isn't unrestricted building. It's distributed building inside sensible guardrails.

I think our industry is unusually well suited for this next generation of citizen developer.

Print and promo businesses are full of workflows that cross multiple systems and organizations. A salesperson builds a project, a presentation becomes an order, artwork has to be collected and approved, purchase orders go out to suppliers and decorators, inventory may come from one company while decoration happens at another, tracking data needs to come back, invoices need to reconcile, and exceptions happen everywhere. Every distributor, supplier, decorator, and technology provider seems to run a slightly different version of the process.

Historically, someone could understand that workflow incredibly well and still have very little ability to change the technology supporting it. They had to explain the process to a developer, submit a request to IT, wait for a software vendor, or simply live with the manual work.

No-code changed that. AI-assisted development expands it further. Someone who understands promotional products operations can increasingly build the connective tissue themselves. They don't need to become TypeScript developers so much as understand the process, the systems, the data, and the outcome they're trying to create. That's a much more accessible skill set, and in many cases, the people with that knowledge are already sitting inside the business.

We've seen this firsthand. We've built order-hold logic for a couple of company stores on the same commerce platform: one flags orders that go over a buyer's credit limit, another holds an order until a purchase order gets approved and uploaded, then releases it to fulfillment. Neither project was really a coding problem. The hard part was deciding what "on hold" should actually mean and which exceptions needed a human. We've done similar work on the reporting side, reconciling order and invoice data between a client's sales platform and their CRM so the numbers they report internally actually tie out. None of that required a computer science degree. It required knowing exactly how orders, invoices, and fulfillment are supposed to work in this industry, and where they usually don't.

For a long time, citizen development was closely associated with the phrase "no-code." I'm not sure that will remain true.

The next generation of citizen developers may generate quite a lot of code. They just won't necessarily write it themselves. Their job will increasingly be to understand the business, architect the solution, give technology the right instructions, test the result, recognize when something is wrong, and continuously improve the system.

In other words, the technical barrier is moving. The valuable skill is no longer simply knowing how to tell a computer how to do something. It's knowing what should happen, why it should happen, and whether what was built actually works.

I'll admit some of this makes me uneasy. Composing Zaps step by step has been a big part of how I've made a living. But that was never really the point of starting PromoPilot. I started it to be a voice in an industry that doesn't hear this enough: there are people at your company right now who can do very cool things with Zapier, and you don't have to be a coder to do it. That's the idea behind our coaching and the courses we run in our Aviators community. If AI makes that even truer, if more people who understand this industry can build the connective tissue themselves without a computer science degree, that's not competition for the mission. It is the mission, arriving faster than I expected.

And that potentially opens the door to a much larger pool of people capable of building the software that moves our businesses forward.

When we're working with suppliers in commonsku, there are times we want that supplier information available in Zoho CRM as well.

We built a custom button that takes the supplier information from commonsku and sends it directly into Zoho CRM. What used to involve copying and pasting between two systems is now a single click.

We added another button that syncs contact information from commonsku to the matching contact in Zoho CRM. Before making any changes, PixieBrix displays a comparison window that shows the existing CRM data alongside the updated information from commonsku.

That gives the user a chance to review everything, make edits if needed, and confirm the update before anything is written to the CRM. It's a small touch, but it gives everyone confidence that the automation is doing exactly what they expect.

We also built a browser mod that reads information from a commonsku sales order and uses it to fill out an inventory receiving log automatically.

Instead of manually copying order details into another system or spreadsheet, PixieBrix gathers the information for us and starts the process with a single click.

It's one of those automations that only saves a few minutes each time, but when you repeat that task throughout the week, those minutes add up.

I've always enjoyed finding ways to automate the repetitive parts of work. Sometimes with Zapier. Sometimes with AI. Sometimes it's a custom app.

Lately, PixieBrix has become another favorite because it fills a different niche. Instead of connecting systems behind the scenes, it improves the experience of the software I'm already using.

I no longer assume that every missing feature has to stay missing. If there's something that would save a few clicks, reduce copy-and-paste, or bring information together in a better way, there's a good chance we can build it ourselves.

That's a fun way to think about software.

Most automation conversations in promo start with the easy wins: syncing orders, pushing data between your CRM and your ERP, triggering a Slack alert when a payment posts. Eric covers a lot of that ground on this blog, and for good reason — those Zaps save real hours every week.

But there's one part of the order that almost everyone still does by hand: the artwork.

A customer uploads a logo. Someone on your team opens it, squints at the resolution, redraws it if it's a JPG pulled off a website, drops it onto a product mockup, sends a proof, waits for approval, fixes the placement, sends another proof, and finally exports a production-ready file the decorator won't bounce back. Multiply that by every line on every order, and the "creative" step quietly becomes the most expensive, slowest, most error-prone part of your operation.

Think about what a single proof actually costs. It's not just the few minutes of design time. It's the email thread. The "can you make the logo bigger" reply that lands two days later. The version that goes to production with the wrong Pantone because someone eyeballed it. The reorder that doesn't match the first run because the setup lived in a designer's head instead of a system.

None of that shows up cleanly on an invoice, which is exactly why it's so dangerous. It hides in turnaround time, in rework, in the orders your team can't take on because they're stuck shepherding proofs for the orders they already have.

Artwork automation is the idea that everything between logo upload and production-ready file can be handled by software, with specs built in, instead of by a person checking each step manually.

In practice that means a system that:

That last point is the one most people miss. When the proof is the production file — not a pretty picture that someone re-creates later — an entire category of "the print didn't match the proof" errors disappears.

Those gains aren't theoretical. For one large print platform, Helloprint, automating artwork across 30+ product categories cut production time by 80%.

The conversion number deserves a second look, because it reframes the whole thing. Proofing isn't only a cost center to be trimmed — it's part of the buying experience. A buyer who sees their logo on the product, rendered accurately, in the moment they're deciding, is a buyer who's far more likely to check out. Speed on the back end and conversion on the front end turn out to be the same investment.

If automating artwork were just "slap the logo on a mockup," every storefront builder would already do it. The reason it's genuinely hard is that promo is a specs business. A mug has a wrap area and a safe zone. A polo has a stitch count and a thread palette. A pen has a print window measured in millimeters where a logo either fits or it doesn't.

Automation only works if those constraints live inside the system. That's why the foundation matters more than the front-end editor: at FastEditor we maintain 500,000+ production-ready product configurations built on real specs from 140+ suppliers, so the output respects each product's actual decoration rules. The decoration method matters too — screen print, DTF/DTG, embroidery, laser engraving, deboss, UV, sublimation, and pad printing each behave differently, and the simulation has to reflect that or the proof is lying to the customer.

Get the specs right and the magic works: the proof is trustworthy, the file is clean, and nobody downstream has to fix anything. Get them wrong and you've just automated the production of bad proofs.

1. Measure your current proof cycle. How many minutes of skilled time per order? How many proof rounds before approval? How often does production kick something back? You can't improve what you haven't timed.
2. Pick one high-volume product category — apparel, drinkware, or pens are common starting points — and automate the proofing there first.
3. Make the proof the production file. This is the single change that removes the most rework.
4. Then connect it to the workflows you've already built. This is where the rest of PromoPilot's playbook comes in: once artwork generation is automated, you can trigger it, route it, and sync it like any other step in your stack.

• Trigger: Customer Created
• Action: Create Contact in Zoho CRM, HubSpot, or Pipedrive.
  

• Trigger: Order Created
• Action: Send Message in Slack or Microsoft Teams.

• Trigger: Order Payment Created
• Action: Create Invoice in your Zapier-supported accounting app.

• Trigger: Order Updated
• Action: Update Row in Google Sheets or Airtable.

• Use separate service or “system” accounts for business-critical connections.
• Avoid embedding your personal login into any automation, unless necessary.
• Look for platforms that let you audit actions by user – not just by workflow.

• If triggering from a form, make sure that only the right people have access to it. Many form tools provide access controls.
• If triggering from an email, verify that the sender is trusted and that inputs are as expected.
• Consider adding a review step before automatically pushing data into another system.