What Makes a Great KotlinConf Proposal?

The KotlinConf 2027 Call for Papers is now open! We invite developers from across the Kotlin community to bring their ideas, experiences, and expertise to the stage in Kraków. Do you have a Kotlin lesson or discovery that could help other developers? Perhaps you solved a difficult technical problem, introduced Kotlin into an existing codebase, built something unexpected, or learned valuable lessons from an approach that did not go according to plan. That experience could become a KotlinConf talk. Submit your proposal However, turning an idea into a convincing conference proposal can be challenging, especially if you’ve never submitted one before. How do you know whether your experience is worth sharing? What do reviewers notice first? How detailed should your abstract be? And how can you make a familiar topic stand out? To help you prepare your submission, we asked Kotlin developers, developer advocates, experienced speakers, and KotlinConf program committee members what makes a strong proposal. Alongside practical advice for shaping your title, abstract, and takeaways, we have added a new section answering an especially important question: What do reviewers notice first when they open a proposal?

First-time speaker? Submit your idea anyway!

It’s easy to assume that a KotlinConf talk must begin with a groundbreaking discovery, a major production system, or years of speaking experience. In reality, a valuable talk can begin with a simple idea or a lesson learned while solving an everyday development problem. You don’t need to know everything about Kotlin – you need something useful to share and a clear idea of who it could help.

Pamela Hill-Galloway. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

X, BlueSky, LinkedIn Submit your idea anyway! There have been some wildly successful talks at KotlinConf that started out as just a simple idea. If you’re unsure whether your topic would interest anyone, discuss it with the people around you. Explain the idea to colleagues, friends, members of a user group, or people in the Kotlin community. Their questions and reactions can help you understand which parts are most valuable.

Marcin Mycek. Product Manager, Kotlin Build Tools

LinkedIn If you can find one interested person, there are probably more! If you can find at least two people around you who find the topic interesting and can listen for more than five minutes, it is already a decent candidate. Previous conference experience is not required. A clear, authentic proposal based on something you understand and care about can be more compelling than a polished proposal with little substance behind it.

Start with the story you want to tell

Before writing the title or opening the submission form, identify the central story behind your talk. “A talk about coroutines” or “a session about Kotlin Multiplatform” describes a subject, but it doesn’t explain what makes the session valuable. Ask yourself:

• What problem, question, or opportunity did you encounter?
• Why was it important or difficult?
• What did you try?
• What surprised you?
• What succeeded and what did not?
• What did you learn that other developers could apply? Your story doesn’t need to come from a large company or a system used by millions of people. A focused lesson from a small project can be just as useful if it offers an original insight or explains a difficult subject clearly. Try summarizing the idea in one sentence, for example: This talk will show [audience] how we [solved or explored something], what we learned, and how they can apply those lessons. If you can’t complete that sentence clearly, the idea may need a little more development before you start writing the proposal.

What do reviewers notice first?

The title may be the first line reviewers read, but the overall level of care quickly becomes visible. Reviewers consider not only whether the topic is interesting, but also whether the speaker can explain it clearly. A thoughtful title, focused description, concrete takeaways, and careful formatting show that you have spent time developing your idea.

Pamela Hill-Galloway. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

X, BlueSky, LinkedIn I can sum it up by saying that the care you take in writing the proposal is probably more obvious than people think. If I can see that you took the time to come up with a catchy or descriptive title that works well with the content, I am more comfortable giving you a thumbs-up to speak at KotlinConf. If your description is so short or so long, or so clearly AI-generated, that you cannot express your idea clearly and neatly, I will probably not vote positively for your talk. This doesn’t mean you need to use complicated language or create a perfect marketing pitch. It means giving reviewers enough information to understand your idea and showing that the proposal represents your own experience and voice. Marcin Moskała’s Taming Asynchronous Beasts: Debugging and Performance Tuning in a Coroutine World provides a good example of a precise promise: “You’ll learn how to effectively use built-in tools, recognize problematic patterns, and implement proven optimization strategies.”

Write a clear and informative title

A strong title should give reviewers, and eventually attendees, an accurate idea of what the talk will cover. Creativity can make a title memorable, but clarity should come first. Avoid titles that rely entirely on a joke, reference, or metaphor without explaining the subject.

Pamela Hill-Galloway. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

X, BlueSky, LinkedIn A carefully-selected title can make all the difference! Audience members often lack the time or attention span to read more than the title when deciding whether to attend a talk. Prefer clarity over a catchy or fun title that doesn’t give a good idea of what the talk is about in a nutshell. Compare the following title examples: Too broad: Our Multiplatform Journey More informative: What We Learned Migrating Our Mobile App to Kotlin Multiplatform Too vague: Coroutines Gone Wild More informative: Debugging Coroutine Performance Problems in Production Too general: Building Better APIs More informative: Designing Type-Safe Kotlin APIs That Are Difficult to Misuse A good title usually communicates at least two of the following:

• The main topic
• The problem or question
• The context in which it was explored
• The practical benefit for attendees
• The expected experience level You can still use humor or wordplay, but make sure the title does not hide what the session is actually about.

Build your abstract around a clear journey

Your abstract doesn’t need to contain your entire presentation. However, it should provide enough detail for reviewers to understand the problem, the direction of the talk, and its value. Two or three focused paragraphs will usually communicate more than either a single vague sentence or a very long description covering every detail.

Sebastian Sellmair. Software Developer and KotlinConf speaker

X, BlueSky, YouTube Talking at KotlinConf is a great experience and a huge achievement for any Kotlin developer. While choosing a great title, having highly polished animations, and curating high-quality memes might enhance your talk, the most important thing is having a story worth telling. Do you have something novel and technically interesting to present? Can you break down a topic in a way that is engaging and truly fun? Can you inspire fellow developers?

Márton Braun. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker

X, BlueSky, LinkedIn While we don’t need a full script for your talk as the abstract, we’re also unlikely to accept a talk where the abstract is just a single sentence. Two or three paragraphs are usually enough to provide meaningful detail. A simple structure can help:

The context

Introduce the situation and the audience likely to recognize it.

The challenge

Explain the problem, limitation, or question that motivated the work.

Jodie Burchell. Developer Advocate and Data Scientist

LinkedIn, Mastodon, BlueSky Hook your audience by telling them the problem you’re going to be solving. People love mystery books for a reason, and that’s because they build up a bit of suspense before they jump into the solution. A great proposal will do the same thing.

The approach

Describe what you explored, implemented, compared, or discovered.

The outcome

Clarify what attendees will learn and how they can use it. A strong takeaway can be as concrete as the one from Tadeas Kriz’s Dependencies and Kotlin/Native: “Learn how native dependencies interact, how they are loaded, and the unexpected complexities of the native world.”

Chantal Loncle. Software Developer, Exposed, JetBrains

LinkedIn Avoid vague promises. Instead, use action verbs and specific outcomes to describe the exact capabilities and transformations the audience will gain. Will they leave your talk feeling that their time was well spent? If so, what practical knowledge, immediately applicable skills, or high-value tools will they take with them? For example: Maintaining separate Android and iOS implementations allowed our teams to move independently, but it also resulted in duplicated business logic and inconsistent behavior between the applications. In this session, we’ll examine how we introduced Kotlin Multiplatform gradually, beginning with one shared feature rather than attempting a complete migration. We’ll discuss how we selected the first component, structured the shared code, tested it across platforms, and worked with the existing native applications. You’ll leave with a practical framework for evaluating where to introduce shared code, which challenges to expect, and how to plan an incremental Kotlin Multiplatform adoption without rebuilding your entire application. The example establishes the problem, explains what the session will cover, and gives the audience a reason to attend. It doesn’t reveal every detail, but it makes a concrete promise.

Think like an attendee

A strong proposal doesn’t focus only on what the speaker wants to present. It also explains what the audience will gain. Ask yourself:

• Who is this session for?
• What knowledge should attendees already have?
• What problem will the talk help them solve?
• What will they understand or be able to do afterward?
• Why should they choose this session over another talk happening at the same time?

Svetlana Isakova. Team Lead in Kotlin Developer Advocacy, KotlinConf Program Committee member, and KotlinConf speaker

X When submitting a talk, think like an attendee. Would you want to sit through this? What’s in it for the audience? That’s why we ask about key takeaways. What do you want people to learn, try, do, or feel inspired by? Avoid broad promises such as:

• “You will learn best practices.”
• “We will explore Kotlin Multiplatform.”
• “This talk will cover coroutines.” Instead, describe specific outcomes:
• Attendees will learn how to identify and debug three common coroutine performance problems.
• Attendees will understand how we structured shared code across Android and iOS.
• Attendees will be able to evaluate whether the approach fits their own project.
• Attendees will learn which parts of our migration worked, which did not, and what we would change today. Specific takeaways make the proposal easier to evaluate. If the talk is selected, they also help attendees decide whether it is relevant to them.

Make a familiar topic feel fresh

Your subject doesn’t have to be completely new. Many valuable conference talks revisit established technologies from perspectives that have not been explored in the same way before. If you are proposing a popular topic, identify what makes your version distinctive. This could be:

• A real production case
• An unusual scale or env