How to run a paid beginner coding workshop

A beginner can spend the first half of a coding workshop trying to install the thing everyone else is already using. The instructor keeps teaching, the person beside them offers a few hurried suggestions, and their paid morning becomes a lesson in feeling behind.

You can prevent a lot of that before opening the room. Build the workshop around one small result, check the actual device and software requirements before people arrive, and pay for enough teaching support to help someone recover without stopping everyone else. Then price the session around the work it takes to deliver that experience.

For a first paid beginner coding workshop, I'd choose a narrow, useful project over a tour of several programming languages. A simple web page that attendees can change, save and reopen gives you something concrete to teach and check. You can explain exactly what the ticket buys, rehearse the whole session and see whether people leave able to do what you promised.

This guide uses an illustrative adult workshop throughout. Ten participants bring laptops to a three-hour introduction to HTML and CSS, the code used to organise and style a web page. They make a small personal project page, practise changing it and take home their files. The teaching plan, prices and costs below are invented planning examples, not market rates or recommended class sizes. Adapt them to your instructor, audience and venue.

Choose a result you can teach in the time you've sold

"Learn to code" is too broad to organise a morning around. It can mean understanding a few ideas, making a first page, writing a program or preparing for a different job. A buyer needs to know which experience you're offering before deciding whether it's worth paying for.

Our workshop promise is specific. By the end, participants will have changed the text and appearance of a simple page, explained which file controls each part and saved a copy they can reopen at home. They start with prepared files. They won't create every line from an empty document, publish a commercial website or build an application that accepts payments.

That scope makes the lesson easier to plan. The instructor needs an example page with a heading, a short introduction and a few project details. The exercises teach attendees to find the relevant code, make a change and check what happened. Publishing the page online can wait for a separate session because account setup and hosting introduce another set of decisions.

Mozilla's first website guidance encourages people to start small and distinguishes the structure, styling, interactivity and publication of a website. Use that distinction when choosing your offer. A short introduction can teach one part well without pretending to cover the whole process.

Talk to the instructor about what the learner will actually do. If the promise includes independent changes, there must be time when attendees work without copying every instruction. If it includes personal feedback, someone has to look at each person's work. A finished page copied from the projector doesn't establish either outcome.

Choose an audience with a reason to care about the project. Adults curious about web development are different from shop owners expecting to replace their business website next week. The latter may need a different session and a more demanding result. Avoid attracting both with a vague headline and hoping the instructor can reconcile their expectations in the room.

Write the exclusions in ordinary language. "No previous coding experience needed; you should be comfortable opening a folder, typing and using a web browser" tells a buyer more than "beginner friendly." Explain whether the class suits someone who needs help with those basic computer tasks. If it doesn't, offer a clear contact route rather than letting them discover that after purchase.

Match the project to a workable device and software plan

The best teaching environment is the one your intended beginners can use with the fewest unresolved steps. That doesn't always mean a browser tool. A browser service may require an account, a subscription, a working connection or permission to store code. A local editor may need an installation that a work laptop blocks. You need to inspect the complete route.

For our example, the instructor prepares a folder containing a basic HTML file and a CSS file. Participants use a tested code editor and a desktop browser. They open the page locally, make changes in the editor, save and refresh the browser. The lesson doesn't require a public account, an online hosting service or a paid software subscription.

This is a deliberate choice for this project. It isn't a rule that every workshop should avoid online tools. A different class might need a managed browser environment because that serves its audience better. If so, check sign-up, export, accessibility, age requirements and what happens when the service is unavailable before making it part of the ticket promise.

Mozilla's software setup guide explains the role of code editors and browsers in web development. Let the instructor choose and test the exact tools for your session. Don't turn that source into a requirement to install every tool a professional developer might eventually use.

Publish your supported setup in enough detail that someone can check it. Name the laptop types and operating systems you've rehearsed, the browser and editor, any installation permissions needed and whether tablets or phones can participate. If you only tested a particular route, say so. "Bring any device" creates a much larger support commitment than it appears to.

Ask about employer-managed computers early. Someone may be able to browse freely but lack permission to install software or download a folder. Never advise them to bypass their organisation's controls. Offer a verified alternative, an available loan device or the appropriate cancellation route under the terms you sold.

Prepare the project files so they don't depend on remote pictures, online fonts or a service login. Use harmless sample text and assets you have permission to distribute. If a participant wants to personalise the page, encourage a fictional example or public information. They don't need to bring private customer records to learn how a heading works.

The instructor's setup should resemble the attendees' setup. A demonstration full of custom shortcuts and extra tools can confuse someone who is trying to locate the same button. Write both the Windows and Mac instructions where they differ, and use the same file names in the handout, projection and download folder.

Give buyers a small readiness check before the workshop

Sending an installation link isn't the same as knowing people are ready. The useful check is whether they can complete the first action the lesson depends on. In our example, that means opening the sample page, changing a short piece of text, saving it and seeing the change in the browser.

Send the instructions early enough to help people who get stuck. Our illustrative plan sends them a week before the event, asks for a readiness reply three days before, and provides a short support window before the final arrival message. Those dates are choices for this workshop, not universal deadlines. Move them to fit your cancellation terms and the time your team can actually provide help.

Keep the task small and show the expected result. The buyer should know which folder to open, which file to edit, what to change and what they should see afterwards. A screenshot can help, but include written instructions too. Don't ask a beginner to diagnose an error before you've explained what the successful action looks like.

A useful reply can be as simple as "I opened and changed the sample," "I haven't tried yet" or "I need help." Give the last group a private way to describe the problem. A booking reference and the point where they got stuck are usually more useful than a long survey about their technical confidence.

Don't ask for passwords or remote access to a personal computer as a routine step. A helper can often resolve the problem with the learner describing the screen or sharing a cropped image without private information. If you're offering a more involved support service, agree its scope, consent and working method separately.

The Carpentries' workshop preparation advice includes downloading materials beforehand and testing offline readiness. For our local-file project, take that seriously. Test the complete exercise with the internet disconnected and confirm the resources still open. Keep an approved way to distribute the same files at the venue if someone missed the download.

Track readiness privately against bookings so the host knows who needs attention. A non-response isn't a failed learner or a cancellation. Contact them using the arrangements you've described. If they arrive without having tried, your plan needs a way to assess the device without delaying the opening explanation for everyone.

Where you offer loan laptops, confirm the reservation rather than assuming anyone can take a spare. Test the exact user account, charger, editor, browser and file-saving route. Explain what gets deleted afterwards and how attendees take their work home. Two unprepared spare laptops aren't much help when both need updates at the door.

Hire someone who can teach beginners and agree how help will work

A strong developer can still struggle to teach a first-time learner. Expertise makes it easy to skip the steps that have become automatic. Ask a prospective instructor to demonstrate part of the actual lesson to someone unfamiliar with the tools, then watch what happens when that person makes an ordinary mistake.

You're looking for patient, concrete explanation. Can the instructor explain the difference between the editor and the browser? Do they say when to save? Can they help someone locate the right file without taking over the keyboard and completing the exercise themselves? Their response to confusion matters as much as the finished demonstration.

Agree the preparation work in writing. The instructor should deliver the lesson plan, starter files, completed examples, exercise instructions and recovery copies by a date that leaves time to test them. Include rehearsal, arrival, teaching, pack-down and any promised follow-up in the fee. Otherwise, you'll keep adding unpaid work or discovering costs after tickets have sold.

For the example workshop, one instructor teaches while one paid assistant helps during exercises and supports arrivals. Ten places is the limit we're proposing to rehearse. It isn't an evidence-based staffing ratio. Your suitable number depends on the difficulty of the work, device variation, support needs and how much individual attention you've promised.

The instructor should remain responsible for the lesson. The assistant needs to know the exercise well enough to identify the current step and help someone recover. A host who can scan tickets but hasn't opened the project isn't automatically a teaching assistant. If one person covers both jobs, rehearse the moments when the jobs conflict.

Agree a quiet request for help, such as raising a reusable help card or approaching the assistant. Explain it at the start and offer another option for anyone who can't use it. Avoid publicly ranking people by progress. Beginners need a way to ask without feeling they're making an announcement about their ability.

A useful assistant asks the learner to show the last successful step, reads the current instruction with them and checks one likely issue at a time. If the same issue appears around the room, tell the instructor. A shared correction may be better than repeating the same private repair at every table.

Our paid workshop planning guide explains how to agree the instructor brief and delivery responsibilities. For coding, verify the actual lesson and audience fit rather than treating a job title or certificate as proof that someone can run your paid session.

Build a lesson that lets people recover when they fall behind

The lesson needs places where you can stop and see whether people are ready to continue. For our page, the first check is changing text. The next is changing a style. Later, participants make a small independent change and explain how they know it worked. Each check tells the instructor something useful about the room.

Prepare a recovery copy for each major stage. Someone who has a broken file can keep their own attempt, open the current checkpoint and continue with the next exercise. Explain what changed so they still understand the lesson. Recovery files should provide a way back into participation rather than hide a problem you're unwilling to teach.

The Carpentries' instructor training recommends participatory live coding, where learners work along with the teacher, with deliberate pacing and visible handling of mistakes. Borrow the practical habits: narrate actions, make the text large enough to read and explain a correction as you make it. You don't need to reproduce their programme or imply affiliation.

Give learners time to predict an outcome before running the change. "What do you think will happen when we change this value?" starts a useful discussion about cause and effect. Then let them test it. Avoid asking only whether everyone understands, because a person can understand the explanation while still being unable to find the file.

Keep one main exercise path. For people who finish early, prepare an optional change that uses something they've already learned. They might adjust spacing or add a second project entry. Don't move the whole room into a new topic because two confident attendees are ready, leaving the advertised beginners struggling with the previous step.

Pair work can help if you design the participation. Let people discuss a problem while each has a chance to edit and check the result. If they share one device, agree when they swap control. Tell buyers in advance if sharing is part of the format. Two tickets shouldn't quietly become one person's keyboard time and another person's observation.

Decide what use of AI coding tools fits the lesson. For this first workshop, I'd keep the core exercises independent of an AI account and ask participants to make and explain the changes themselves. You can discuss such tools in questions without making generated code a substitute for the result you sold. If AI is central to another offer, disclose the service, account, costs and data arrangements before purchase.

Rehearse with the instructions exactly as attendees will see them. Don't quietly supply missing steps to the tester and then declare the worksheet clear. Note where they hesitate, which words they don't recognise and how long it takes to recover. Use that evidence to simplify the project before adding more tickets.

Check the room as a working classroom

A room that seats ten people for a talk may be awkward for ten open laptops. Visit or test the actual layout with the venue. Check table depth, chairs, the projected view, accessible routes and the space the assistant needs to reach someone without leaning across another participant's screen.

Sit in the least convenient place and read a short piece of projected code. If it only works when you know what the instructor typed, it isn't readable enough. Ask the instructor to increase the text size and reduce the amount shown. Handouts and files should be available directly to participants so they aren't dependent on reading everything at a distance.

W3C's accessible event guidance recommends planning access support and providing suitable materials ahead of time. Apply that to the teaching files, spoken explanations and room arrangements. Ask about participation requirements privately and agree a response with the learner. Don't assume a larger font resolves every access need.

Show and describe what changes. "The heading became blue" is more helpful than "now it looks like this." Give keyboard instructions where relevant, and test them with the tools you've chosen. If someone uses assistive technology, discuss the actual exercise with them and the instructor early enough to make an informed plan.

Confirm power arrangements with the venue, including where chargers can connect without trailing across routes. HSE's event electrical safety guidance, for Great Britain, covers suitable equipment and cable routing. Have the responsible venue or electrical person assess the setup; the number of sockets you can see isn't a capacity calculation.

Test the network with the activities you will run. A room's advertised Wi-Fi doesn't establish that every laptop can download files or access your chosen service. Our event Wi-Fi guide covers the broader procurement and reliability questions. This workshop's local files reduce dependence on connectivity during the core exercises, but you still need a plan for arrivals and any online resources.

Keep drinks away from borrowed equipment and leave room for bags without blocking movement. Agree who handles a spill, a failed charger or a venue problem while the instructor teaches. Check the first-aid and emergency arrangements with the venue as part of the event plan, rather than assuming the classroom format makes them irrelevant.

This example is an adult class. A children's workshop changes supervision, safeguarding, consent, account eligibility and collection arrangements. Make that a separate operating plan with appropriately checked requirements. Don't simply lower the age on the same ticket page and keep every other arrangement unchanged.

Price the complete delivery, including preparation and support

Start with what the session will cost to deliver as advertised. Coding doesn't use many physical materials, but preparation and support can take substantial paid time. Your instructor's three hours at the front of the room are only part of the job.

Here is our invented budget in USD. The instructor costs $300 including preparation and rehearsal. The assistant costs $120, venue access $150, promotion $60, organiser administration $50 and printed resources $20. Those fixed costs total $700. We've also allowed $5 per attendee for refreshments and other supplies that change with attendance.

Assume each full-price ticket leaves $85 for the event after the ticket-related deductions you've allowed for. That's retained ticket income for this example, not a quoted platform fee or a recommended public price. Check the actual total a buyer pays, your tax treatment, payment charges and refund costs when building your own budget.

Each paid attendee contributes $80 after the $5 variable cost. Nine paid places contribute $720, leaving $20 after the $700 fixed costs. Eight paid places contribute $640, leaving a $60 loss. At ten paid places, retained ticket income is $850 and variable costs are $50, leaving a $100 surplus.

That surplus assumes the listed work and costs are complete. If you need another $100 of instructor preparation, the ten-person session reaches zero. If you keep ten attendees but give one place away, nine paid tickets bring in $765. After $50 of supplies and $700 fixed costs, you have $15 left. The free place still uses teaching capacity and supplies.

Discounts deserve the same treatment. At ten paid attendees, two $10 discounts reduce the $100 surplus to $80, assuming other deductions don't change. Those examples are separate alternatives, not costs to add together. Put each decision into your own budget rather than assuming a nearly full room can absorb it.

Our paid workshop pricing guide develops minimum bookings, discounts and repeat-session decisions. For this class, the immediate question is whether the tested teaching limit supports enough retained income. If the answer is no, change price, costs or the offer before deciding to fit more beginners into the room.

Check cash timing separately. Suppose the venue requires a $75 deposit, included in its $150 total, and you pay $60 promotion before sales open. That's $135 due in advance. You need a way to fund it even if the final budget works. A loan laptop, paid software or extra rehearsal may add another commitment before ticket receipts are available.

Choose a sales decision date before costs become difficult to reverse. Write down the minimum bookings, any affordable first-run investment you're deliberately accepting and the cancellation arrangements you've sold. Don't let an imagined advanced workshop pay this one's bills. Future sales can inform a business plan once you have evidence, but they aren't confirmed income for this date.

Make the ticket page answer the questions beginners hesitate to ask

The buyer may be worried about being the only person who doesn't know anything. They may also wonder why they'd pay when so many tutorials are free. Answer both concerns with the actual experience you're providing.

Explain that the ticket includes guided practice, a prepared project, help during the exercises and a chance to check the result with the instructor. Show a realistic beginner example and identify it as an example. An elaborate professional portfolio can establish the teacher's skills, but it doesn't show what someone will achieve during your morning.

Loopyah's ticket-selling tools let you set ticket types and quantities, with confirmation emails linking to buyers' QR tickets. Use that booking record for the paid places you've actually planned. The event page still needs your accurate device requirements and teaching promise; admission software doesn't establish that a laptop is ready for class.

Give the essentials before someone buys:

• The project, intended audience and basic computer skills needed.

• Date, teaching hours, arrival time, venue and access information.

• The supported laptop, editor and browser setup, including installation permission.

• Whether software, accounts, subscriptions or loan equipment cost extra.

• What is included, how individual help works and what follow-up you provide.

• The total price and the terms for cancellation, transfers or organiser changes.

A draft description could say: "Make your first simple web page in a guided beginner workshop. You'll edit text and styling, practise checking your changes and leave with files you can reopen at home. No coding experience is needed. Bring a supported laptop and charger, and complete our short setup check before attending. This session doesn't include online publishing or a professional qualification."

Add the precise setup and other details below that paragraph. Don't conceal a paid subscription or compulsory preparation inside the post-purchase email. If a buyer can't use your requirements, they need to know before committing money and travel time.

Loopyah's Worth It Event Index surveyed 500 US respondents through Pollfish on 11 February 2026. Asked how clear they felt about the experience before buying an event ticket, 26.2% answered "a great deal," 36.6% "a lot," 31% "a moderate amount," 5.8% "a little" and 0.4% "none at all." The full report contains the question and distribution.

This is a general event survey, not research on coding students, and it doesn't measure what a clearer page would do to your sales. It gives useful context for the uncertainty a buyer can bring. Your workshop description should make their practical decision easier without promising results the survey never tested.

Promote the teaching experience and use questions to improve the offer

A small demonstration can tell a prospective buyer more than another list of programming terms. Ask the instructor to show a simple text change and explain why the page changes after saving and refreshing. Keep it understandable to the person the workshop is intended for.

Then connect the demonstration to the paid session. Explain that attendees will practise themselves, receive help and save their own work. You don't need to pretend that the code is secret or unavailable elsewhere. The value you're selling is a planned opportunity to learn and practise with support.

Choose relevant audiences. Local adult-learning networks, the instructor's audience and people who have asked about an introductory session may be sensible starting points. A professional developer group may have reach but few people who want this beginner project. Give partners the prerequisites and exclusions so their recommendation attracts the right buyers.

Keep the demonstration honest about preparation. If it uses a fully installed editor and prepared files, say that. Don't make an effortless-looking clip and then surprise buyers with a difficult setup. Show enough of the actual teaching style for someone to judge whether it suits them.

Record repeated questions. If buyers keep asking whether a work laptop will do, improve the device section and offer a way to check before purchase. If they expect a business website, strengthen the explanation of the finished project. You may need to change the audience or promise rather than spending more to repeat an unclear advertisement.

Watch paid bookings against the decision date. Likes, expressions of interest and free-event attendance don't establish that people will pay your planned price. Use actual bookings and the stated budget when deciding whether the first session can proceed. Keep any deliberate test loss explicit and affordable.

Avoid overstating career benefits. A first coding experience can help someone explore an interest. A short workshop alone doesn't justify promises of employment, professional competence or a salary change. Describe the skills attendees practise and the work they take home. That is already a useful offer when the teaching is good.

Give the team a rehearsal with an actual failure

A smooth run on the instructor's own computer doesn't test the paid experience. Set up a practice session where the organiser plays a learner and the assistant follows the written support instructions. Use the actual room if possible, or at least the same display connection and equipment.

Try opening the wrong copy of the project, forgetting to save and disconnecting the network. Ask the assistant to help without replacing the learner's work. These are deliberately chosen rehearsal situations, not a prediction of how often attendees will have problems. The point is to discover whether the team can recognise a recoverable mistake and explain the next action clearly.

Also test a problem that takes someone out of the exercise. Suppose a laptop won't start. Who checks the loan reservation, who transfers the learner to a tested machine and who keeps the opening explanation moving? Record a practical limit on how long one helper can investigate before using the agreed alternative. You don't want the only assistant spending the whole first exercise on a repair that needs a specialist.

Give the organiser a short contact sheet with the venue contact, instructor, assistant and equipment owner. Keep the current file folder and running order in a known place. If the instructor becomes unavailable before the event, the existence of their slides doesn't mean an unprepared substitute can deliver. Assess whether a qualified replacement can teach the promised session, then communicate the actual decision under your event terms.

Finish rehearsal by walking through the final export or file transfer. Reopen the learner's copy on the device they will take away. If that step depends on an account or connection you hadn't planned for, fix the arrangement now. The exercise is complete when the attendee has usable work, not when the projector shows the instructor's finished page.

Run a three-hour session with protected practice and saving time

Our example teaches from 10 am to 1 pm. Venue access, setup, arrivals and clearing the room happen outside that period and are included in the relevant costs. The following running order is an illustrative plan to rehearse, not a timing standard.

• 10:00 to 10:15: welcome, explain the project, show the help system and check that everyone can open the starter page.

• 10:15 to 10:40: demonstrate a text change, let attendees try it and check that each person can save and refresh.

• 10:40 to 11:10: guide a styling exercise with time for questions and recovery copies.

• 11:10 to 11:25: break, with the team checking any unresolved setup problems.

• 11:25 to 12:05: independent project changes while the instructor and assistant circulate.

• 12:05 to 12:30: practise finding and correcting a small mistake, then complete unfinished core work.

• 12:30 to 12:50: review the result and check that each person can explain one change they made.

• 12:50 to 13:00: save, close and reopen the project, then explain resources and the agreed follow-up.

That's 180 minutes including a 15-minute break. Put a clock where the instructor can see it, and agree which optional content disappears if an exercise overruns. Protect the final save and reopen check. A participant shouldn't discover on the train home that their work existed only in a temporary window.

At each check, ask for an action. Can they change the heading without a fresh demonstration? Can they show which file they changed? If the page doesn't update, can they check whether they saved and refreshed the right file? These are modest tests of the promised skills, not an exam or a professional assessment.

Keep a copy of the current exercise available to the assistant so a late arrival can join without interrupting the instructor. Agree the limits. Someone who misses most of the session may need a different remedy under your stated terms; the assistant can't privately reteach the entire morning while helping everyone else.

If several devices fail together, pause and assess whether you can still deliver. Switch to the rehearsed fallback only if it preserves meaningful participation. Watching the instructor finish alone is a different experience from the hands-on workshop people purchased. Explain a material change honestly and apply the arrangements relevant to your event and buyers.

Send useful files and close the accounts before booking the next date

Before attendees leave, check that they know where their project is saved and how to reopen it. If they used loan equipment, complete the transfer while help is still available. Don't ask them to email private files to a shared public address or leave their only copy on a machine you're about to reset.

Send the promised resource pack on the schedule you gave them. Include the starter folder, completed example, exercise instructions, common fixes and a clear route for the follow-up you've actually funded. If the offer includes one week for questions about the exercises, define the end date and who answers. Avoid promising unlimited technical support for an introductory ticket.

Separate a factual resource message from invitations to buy another workshop. Apply the marketing permissions and rules relevant to your recipients when promoting the next date. Booking a class doesn't settle every question about future promotional messages.

Ask about the experience in terms that lead to changes. Could attendees complete the setup? Where did they need help? Did the description match the session? What could they change independently afterwards? A positive rating is useful, but it won't tell you that four people lost the same file or that the projector was unreadable from the back.

Review those answers with the instructor and assistant. Record the exercise that took longest, the repeated device problems and how often a recovery copy was needed. Keep personal support information private and retain only the records you need. Change the files and preparation instructions while the problems are still clear.

Then compare actual income and costs with the budget. Include refunds, extra support, unused room time and preparation you forgot to price. In our example, ten paid places produce a planned $100 surplus. An unplanned $100 support invoice removes it. A full class tells you there was enough demand for ten tickets; it doesn't establish that the format paid properly for the work.

Decide what the next date should test. You might keep the same project and improve setup, increase the price to cover proper preparation or reduce device variation by providing tested equipment. Each choice changes costs and the buyer's decision. Recalculate before announcing the next session.

Interest in an advanced topic is worth recording, but ask what people want to be able to do next. "More coding" is still too broad. If enough learners want to put their page online, investigate a separate publishing workshop with its own prerequisites and account plan. Confirm that demand before committing to another venue booking.

Before opening sales, run the readiness task and the entire lesson with someone who matches your intended audience. Watch where they need help, price the support it takes and rewrite the ticket page around what you can deliver. That test gives you a far better basis for a paid beginner workshop than the amount of code the instructor can write in three hours.