How to plan a paid developer conference with practical technical sessions

You've booked a speaker with a strong technical reputation. Their session promises a working application by lunchtime. Then the room fills up, half the laptops can't install the required software, and the speaker spends the first hour fixing accounts. Everyone bought a workshop. Very few people get one.

That's the planning problem a paid developer conference has to solve. You need a programme worth travelling for, a budget that supports proper delivery, and technical sessions that work for the people who actually arrive. A famous speaker and a room with Wi-Fi won't do that on their own.

Start with the work your audience wants to get better at. Choose sessions that address it, specify the knowledge and equipment each session needs, and test the experience before selling more places than you can support. Keep sponsorship clearly labelled so buyers understand which sessions were selected for their learning value and which were purchased.

We'll work through a fictional first edition for working developers, including a separately ticketed practical workshop. All example amounts are USD planning assumptions, not market prices or conference benchmarks. For the general venue, supplier and ticketing sequence, use our paid conference planning guide. Here, the focus is what changes when your audience expects useful code, credible technical discussion and time to ask difficult questions.

Choose the developer you can genuinely help

"A conference for developers" leaves too much undecided. Someone maintaining a large business application has different questions from someone building their first website. They might use the same programming language and still have very little reason to attend the same workshop.

Describe your likely buyer through their work. Perhaps they maintain services that other teams depend on, and they need to make changes without breaking those services. That gives you a useful programme direction. A session about diagnosing failures, a migration case study and a testing workshop can serve the same audience without repeating one another.

Talk to people who fit that description before committing to the format. Ask what they struggled with recently, where existing documentation stopped helping, and which technical decisions they would like to discuss with someone experienced. Ask what would justify taking a day away from delivery. The answer may involve employer approval, travel or a project deadline as much as ticket price.

Be careful with enthusiastic feedback from your own community. People can like the idea and still have no budget or permission to come. Show a realistic outline, location and indicative price. Ask which session they would choose and what they would need to get the purchase approved. Specific objections help you plan more than general encouragement.

You don't need to serve every experience level. In fact, a first edition usually becomes easier to explain when you choose a narrower audience. If you include introductory sessions, say what they introduce. If you promise advanced content, explain the knowledge people should already have. Years in a job are a poor substitute for that explanation.

Write session descriptions people can choose from

A technical session needs a clear outcome. "Modern application architecture" could mean almost anything. "Compare two approaches to splitting a shared database, using a worked migration example" tells a buyer what they will spend their time considering.

For each session, agree the problem, expected prior knowledge, activity and useful result. A talk might help delegates evaluate a tradeoff. A workshop might produce a small working example they can modify. A discussion might compare several approaches without producing code at all. Those are different experiences, and none automatically offers more value than the others.

PyCon US's 2026 tutorial proposal guidance asks instructors to describe audience experience, exercises, timing and internet needs. That's a useful example of the detail a programme team needs before accepting a practical session. The guidance also asks how instructors will handle people who arrive without having prepared and how the tutorial can continue if connectivity fails.

Use that distinction in your own descriptions. If attendees will mostly watch a demonstration, call it a demonstration. If they will write code, explain how much of the session involves exercises and what help is available. Don't advertise hands-on participation when the room layout or staffing only supports watching someone else's screen.

Make prerequisites concrete. "Intermediate" tells a reader less than "You can run a small application locally and are comfortable reading automated tests." Describe any required language or framework separately. A developer can be experienced in one area and completely new to another without being the wrong person for the conference.

Also explain what the session will leave out. A workshop on investigating slow database queries might cover reading execution plans but exclude production database administration. Buyers can then choose for themselves. This makes the speaker's job more manageable too, because they have a defensible boundary when questions start expanding the session.

Consider a workshop on changing an application without breaking its existing behaviour. The instructor plans a short explanation, a deliberately failing example and an exercise where attendees make a change safely. That outline lets you ask useful questions before accepting it. Does the example demonstrate the problem clearly? Can someone with the stated prerequisites complete the exercise? What happens if they get stuck before reaching the main lesson?

Now compare two proposed versions. One begins with a long overview of the instructor's preferred framework. The other starts with a small application and shows why an apparently reasonable change fails. For the audience we described, I would favour the second. They are paying to improve a decision they make at work. The framework can still appear when it helps explain that decision, but it shouldn't consume the time reserved for practice.

Build a programme that leaves time to learn

Start with one coherent route through the day. You might open with a shared technical problem, follow it with contrasting implementation examples, then make time for attendees to question the speakers. A separate workshop can let people practise the part that needs patient instruction.

Resist adding tracks merely because more speakers are available. Each additional room creates another production setup, another host and another set of clashes. If your audience shares a common problem, a single track gives everyone the same reference points for later discussion. Add parallel sessions when the audience genuinely needs different routes and you can operate them properly.

Check the programme from the attendee's point of view. Can someone with the advertised prerequisites follow a useful sequence? Have you scheduled their most relevant sessions against one another? Are they expected to leave a workshop halfway through to hear the keynote? A full timetable can still produce a frustrating ticket.

Practical sessions need space around them. People need to arrive, connect power, open the exercise and ask for help without consuming the entire teaching period. If you're offering short talks and longer labs, publish their different durations clearly. A room change should include the actual walk, including the accessible route, rather than an optimistic gap on a spreadsheet.

Our guide to movement between conference rooms covers that part in more depth. For this event, put workshop check-in near the workshop and let the technical helper meet attendees before teaching begins. A general registration desk across the building can't resolve a missing account while the instructor is waiting to start.

Leave some unprogrammed time for technical conversations. You can help by hosting discussions around specific problems, with a moderator who welcomes newcomers. Avoid assuming everyone will introduce themselves comfortably in a noisy reception. A small table discussing a concrete challenge may be more useful than another presentation squeezed into the afternoon.

Give the programme owner authority to refuse a late addition that cannot be prepared properly. A sponsor request, newly available speaker or fashionable topic can sound attractive in isolation. Ask whether it serves the chosen audience, whether the delivery team can test it and what it displaces. Keep the published promise achievable. People will judge the conference through the sessions they attend, including the rushed ones.

Calculate the workshop economics separately

A conference pass and a workshop place do not have the same costs or capacity. Your main room might hold hundreds, while a practical session is limited by desk space, equipment and the amount of help one instructor can provide. Keep the workshop calculation separate before combining it with the event budget.

Suppose our fictional workshop has 40 paid places. Each place provides $180 after taxes and ticketing or payment charges. Attendance-related costs are $30 per person, including refreshments and materials. The remaining $150 per place contributes towards $4,500 of fixed workshop costs. Those fixed costs include the room, instructor, technical helper, preparation, equipment and a contingency allowance.

The workshop therefore needs 30 paid attendees to cover those specified costs. At 20 attendees it loses $1,500. At 40 it produces $1,500 before any business expenses outside this example. The figures below come directly from these assumptions, using retained ticket income minus fixed and attendance-related costs.

That's a thin enough margin to make preparation decisions matter. If another $900 of equipment becomes necessary, the break-even point rises to 36 places at the same contribution per attendee. You now have much less room for weak sales. Confirm technical requirements before treating a workshop as an easy source of extra income.

Reserve any complimentary places explicitly. A sponsor guest using a desk still uses capacity and incurs attendance-related costs. If they take one of the 40 places, you have fewer places available to sell. Don't calculate revenue as if every desk were paid and then add guests afterwards.

Use our event break-even guide for the wider calculation. Then agree a workshop sales review before cancellation costs increase. If demand is too low, decide whether to proceed, change the arrangement with the instructor or cancel under the terms buyers accepted. A smaller workshop can be excellent, but someone still has to fund it.

Choose equipment around the actual exercises

Before requesting venue quotes, ask each instructor for the exercise they intend to run. You need to know whether people will type throughout, work in pairs, use external hardware or mostly watch. These details change the furniture, power, connectivity and support you need to buy.

A theatre layout may suit talks but frustrate people balancing laptops on their knees. For a practical room, check usable desk space, sightlines, accessible circulation and where bags will go. Count workable places after the production equipment and access arrangements are included. The room's largest advertised capacity is not your workshop capacity.

Have the venue and qualified suppliers agree the power arrangement. Tell them how many laptops and other devices you expect, where they will be used and which equipment the organisers supply. Ask them to confirm safe distribution and cable routing. A collection of spare extension leads is not an electrical plan.

For connectivity, describe the activities instead of asking whether the venue has "good Wi-Fi". Will everyone download a large project at once? Will exercises call an external service? Does login depend on a company identity system? Ask the network supplier how the proposed setup supports that use, including concurrent devices and access to required services.

Test a representative exercise using the network attendees will actually join. A successful test on the venue office connection doesn't establish that the guest network permits the same traffic. Confirm who can fix a network problem on the day and whether that person will be present during the practical sessions.

Projection needs its own test. Open real code in the speaker's editor, including error messages and terminal output. Sit at the back and check whether it is readable. Agree the connectors, audio needs and display settings in advance. The most technically correct demonstration is useless to the people who can't see what changed.

Reduce setup work before people reach the room

Choose the simplest environment that can teach the promised lesson. A workshop on reading test failures should not require attendees to recreate an entire production system. Every additional dependency creates another opportunity for a version conflict, blocked download or account problem that has little to do with the learning outcome.

Ask the instructor to create a clean starting point and test it on a fresh machine or account. Then have someone outside the teaching team follow the instructions exactly. Experienced instructors often fill gaps unconsciously because they already have the tools installed. Your test should reveal what a new attendee actually encounters.

If preparation is needed, publish it before purchase and repeat it in the workshop information. Include supported operating systems, required permissions, downloads and a simple check that confirms readiness. Give people a contact for problems. Don't introduce a paid account requirement after they have committed to a ticket advertised as including the practical session.

A browser environment can reduce local installation, but it brings its own conditions. GitHub's Codespaces billing documentation explains that usage includes compute and storage, with billing assigned according to account and organisation settings. If you choose that approach, confirm who pays, which accounts can use it and when the environment will be removed.

Company laptops deserve particular attention. Attendees may be unable to install software, create external accounts or use certain cloud services. Offer a supported alternative where practical and state its limits. Watching a partner complete an exercise can be useful, but it should be an agreed participation option rather than an improvised answer to a preventable access problem.

Keep a copy of the exercise materials that does not depend on a single website remaining available. A local dataset, prepared project and written walkthrough can preserve useful teaching during an outage. Check permission to redistribute any materials you supply. Preparation is complete when another person can use it, not when the instructor sends a repository link.

Rehearse the demonstration and its failure

Ask speakers to rehearse the session they will deliver, including the demonstration. A slide review won't reveal a slow build, a request for unexpected permissions or a dependency on information that only exists on the speaker's own machine. These are ordinary delivery details, and they need time in the production plan.

Use a harmless practice dataset and accounts intended for the event. Ask speakers to remove real customer details, private messages and credentials from anything they might share. Check the desktop as well as the application. Notifications, browser tabs and command history can reveal information the speaker never intended to present.

Agree what happens if the live demonstration stops working. The speaker might switch to a prepared project at the next completed stage, show a short recording, or explain the result through saved output. The alternative should still teach the point. Repeating a failed command while everyone waits rarely does.

Set a clear limit on troubleshooting during teaching. For example, an instructor could ask a helper to investigate an attendee's setup while the rest of the room continues. If the common environment fails for everyone, the host should announce the agreed alternative. Decide this during rehearsal so nobody has to negotiate the response on stage.

Keep a named technical lead available to the event team. That person coordinates the venue connection, production crew and instructors when a problem crosses responsibilities. Our guide to on-site event technology support explains how to decide what support to buy. A volunteer who can greet attendees should not automatically inherit responsibility for a failing lab environment.

Record what worked in rehearsal, what remains unresolved and who owns each fix. Recheck changed materials before doors open. An instructor who updates the project the night before can accidentally invalidate the instructions attendees already followed. Ask for a stable teaching version, with any essential late change explained to the people affected.

A useful rehearsal includes the handover as well as the code. Have the room host introduce the session, confirm the microphone works and explain how questions will reach the speaker. Then let the speaker move between slides, editor and prepared fallback. Watch for the small interruptions that disappear when one person tests alone, such as a display switching resolution or an audio cable preventing the laptop from reaching the lectern.

Ask a colleague to play an attendee who missed the preparation email. They should arrive with only the information a ticket buyer received. Can the helper identify the problem and offer the promised alternative without stopping the class? If the answer depends on the instructor leaving the stage, revise the arrangement. You're testing whether the session can accommodate a predictable problem while continuing to serve everyone else who paid.

Give helpers a realistic job

Practical sessions need help that matches the activity. Start by asking the instructor what tends to go wrong and which questions a helper must be able to answer. Someone who can manage the room might still be unable to diagnose the exercise. You may need both roles, with different responsibilities.

Don't choose a universal helper ratio from somebody else's event. Test your exercise with a small group and observe where people need attention. If several people get stuck at the same step, improve the instructions first. If the exercise requires frequent individual explanation, reduce the room size or budget for additional qualified help.

Tell attendees how to request assistance without interrupting everyone. The instructor can explain this at the start, and helpers can introduce themselves near the relevant desks. Make the approach workable for people who cannot easily raise a hand or speak across the room. A quiet request should still reach someone who can respond.

Agree the help boundary too. Your team can assist with the published workshop environment; it may not be able to repair a company laptop or bypass an employer's security policy. Explain the alternative participation route respectfully. People should know what support the ticket includes before they discover a problem in front of their colleagues.

Build breaks into the teaching and staffing plan. Helpers need time to reset materials, talk to the instructor and deal with issues that would otherwise interrupt the next exercise. If the same person must simultaneously register late arrivals, manage the microphone and fix accounts, you haven't assigned enough support for the session you've promised.

Set sponsor boundaries before selling packages

Developer audiences can find a vendor demonstration useful. They can also recognise when an advertised technical talk becomes a sales presentation. Be explicit about what sponsors can buy and what remains subject to independent programme selection. That protects the attendee's ability to choose and the sponsor's understanding of the agreement.

You might sell a clearly labelled sponsored demonstration, an exhibition space or support for an evening gathering. If a sponsor employee submits a regular technical talk, apply the same selection criteria you use for everyone else. Sponsorship should not quietly remove the requirement to teach something useful.

PyCon US's 2026 sponsor presentation schedule identifies those presentations and their sponsors. Your programme can use the same basic principle of clear identification without copying another conference's commercial model. Put the label where people select sessions, including the agenda and session page, rather than only in a footer.

Write the boundaries into the package and agreement. Specify the format, duration, branding, equipment and any review deadline. Explain whether attendee interaction is optional and how the sponsor may collect contact details. Don't promise access to personal information simply because a company has paid for a booth or session.

With Loopyah's event sponsorship tools, you can publish priced packages on a private page and require approval before a brand pays. That gives you a way to review the proposed sponsor before accepting the package. You still decide the editorial rules and whether its proposed activity fits the audience.

Cost sponsor delivery before counting the income. An extra demonstration room may need production, furniture and staff. Sponsor passes may reduce paid capacity. Ask what remains after those commitments. A package that helps finance the conference should improve the event's finances without leaving the programme team to repair promises made during the sale.

Make the technical experience accessible

Accessibility belongs in the session brief from the beginning. A developer who uses assistive technology needs access to the exercise and the explanation, as well as the building. Ask about requirements through a clear contact route and share relevant information with the people who can arrange support.

W3C's accessible events checklist recommends accessible materials, describing relevant visual information and planning for microphones, captioning and participant needs. Apply that to code sessions. Ask speakers to explain what they change and what the resulting output means, rather than assuming everyone can follow rapid edits on a projected screen.

Provide readable materials attendees can open on their own devices. Check whether the exercise requires a mouse gesture, colour distinction or timed action that excludes a participant. Work with the instructor on an alternative route that preserves the lesson. A larger font on the main screen won't resolve every barrier in an interactive environment.

Give captioners or interpreters the terminology and materials they need in advance. Technical vocabulary, product names and code can require preparation. Confirm how they receive the speaker's audio and where attendees can see the information. Include these arrangements in rehearsal rather than treating them as a separate service that somehow connects itself.

Publish a conduct policy and a practical reporting route. The Python Software Foundation's code of conduct is one primary example of stated expectations and reporting guidance. Your own team needs trained contacts and an agreed response process. A policy link alone does not help someone find assistance during a difficult conversation.

Sell the experience you have confirmed

Your sales page should explain the audience, programme, prerequisites and ticket inclusions in terms a buyer can check. If workshops are separate, say that near the price. Explain whether a conference pass includes every session or whether limited places require an additional booking.

Before opening sales, test the whole purchase path for each ticket option. Confirm what the buyer receives and how your team recognises their entitlement at the workshop door. A workshop allocation must stay within its real capacity even if the main conference still has tickets available. Check cancellations and transferred places as well as new purchases.

Give employer-funded buyers a useful explanation they can forward. Connect the sessions to work they actually do, list the practical outcomes and provide the administrative information required to approve payment. Avoid promising a financial return you can't substantiate. A clear account of what the employee will learn is more credible than an invented productivity claim.

Send workshop information to the people attending that workshop. Keep general travel information separate from technical preparation so the required action is easy to find. When requirements change, identify the change explicitly and tell buyers whether they need to repeat any preparation. Don't expect them to notice a silently updated document.

Keep changes visible once people have booked. If a speaker replaces the advertised workshop with a substantially different topic, assess what buyers were promised before announcing the substitution. An equally impressive biography doesn't make two sessions interchangeable. Tell affected attendees what changed and explain the options available under your terms and applicable requirements. The programme team should make that decision with whoever handles buyer support, rather than leaving the registration desk to explain it on arrival.

After the event, deliver the materials you promised within the agreed period. Check recordings and code before distribution, and honour the permissions you obtained. Ask whether the session matched its advertised level, whether attendees could participate and which barriers stopped them. Those answers are more useful for planning the next edition than a single overall satisfaction score.

For the next edition, keep the evidence specific to each session. Record attendance alongside the number of places sold, the preparation problems reported and the help actually required. A sold-out workshop can still be unsuitable to repeat if participants couldn't complete the promised work. Equally, a quiet first edition may deserve another attempt if the right audience valued it and you can reach them more efficiently. Separate the quality of the teaching from the effectiveness of your promotion when deciding what to change.

Compare those responses with the workshop's actual costs and sales. If delegates learned what you promised but the margin disappeared into unplanned support, improve the environment or price before repeating it. If the economics worked but people couldn't follow the exercise, fix the session before selling it again. Start the next edition with the evidence you now have about what people could use and what it took to deliver it.