A concise multiplatform language developed by JetBrains
Kotlin KotlinConf
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.
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
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, , 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, , 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
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
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
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 environment
- A surprising result
- A failed approach and what it taught you
- A comparison between several possible solutions
- A gradual migration rather than a greenfield implementation
- An unconventional use of Kotlin
- A personal experience that challenges a common assumption
- A particularly clear way of explaining a difficult concept
For example, “Introduction to Kotlin Multiplatform” is broad and familiar. “What Broke When We Introduced Kotlin Multiplatform Into a Seven-Year-Old Mobile App” offers a specific context and creates curiosity.
Be honest about trade-offs. A talk doesn’t need to present a flawless success story. Explaining what failed, what changed, and what you would do differently can be especially useful to other developers.
Chantal Loncle. Software Developer, Exposed, JetBrains
Bringing a real, practical narrative to a familiar topic can strengthen a proposal. Be honest about what broke, what made your team unhappy, or what you would do differently if you could turn back the clock. A familiar issue can feel fresh when you look at it from the perspective of someone who will encounter the same problem for the first time tomorrow.
Rather than providing another general overview, build the talk around one specific pain point or discovery and introduce broader themes only where they support that story. A takeaway that attendees can immediately apply to their work can also help distinguish the proposal from a basic tutorial.
Keep the proposal relevant to KotlinConf
KotlinConf welcomes talks about backend development, Android, multiplatform development, web, desktop, AI, language design, tooling, libraries, developer experience, and other parts of the Kotlin ecosystem.
Whatever your area, the role Kotlin plays in the story should be clear.
Márton Braun. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker
X, , LinkedIn
Keep in mind that your talk should be related to Kotlin! For example, not every Android talk is necessarily a good fit for the KotlinConf audience. Or talks about Jetpack Compose often cover things that work the exact same way with Compose Multiplatform, and the latter is much more likely to be accepted at KotlinConf!
An Android topic, for example, is not automatically a KotlinConf topic. The proposal becomes more relevant when it explains how Kotlin influenced the solution, explores a Kotlin-specific technical decision, or provides lessons that Kotlin developers can apply.
Ask yourself:
- Why is this a Kotlin story?
- Which parts of the experience are especially relevant to Kotlin developers?
- Would the proposal still be essentially the same if Kotlin were removed from it?
If the answer to the final question is yes, strengthen the connection to Kotlin before submitting.
Anshika Koul’s Kotlin Multiplatform’s Cross-Platform Brilliance at Norway’s 377-Year-Old National Postal Service offers a clear example of a Kotlin-centered takeaway: “We’ll learn how KMP provides a unified framework for code sharing and execution across various platforms to solve the challenge of different codebases targeting different runtimes.”
Sound confident, but stay true to yourself
Your proposal should show that you understand what you want to share and why it matters.
This doesn’t mean exaggerating your expertise or pretending that you have no doubts. It means presenting the idea as a clear statement rather than repeatedly questioning its value.
Marcin Mycek. Product Manager, Kotlin Build Tools
Keep statements as statements and questions as questions. It is normal to doubt yourself; everybody does, but a common mistake is to let it show in the text, for example, by changing statements into questions. Read your submission, or even better, ask someone else to read it, and ask yourself: Does this person sound convinced about what they want to tell?
For example:
Uncertain:Could Kotlin Multiplatform possibly help teams reduce duplicated business logic? In this talk, we might find out.
More confident:In this talk, I’ll show how our team used Kotlin Multiplatform to reduce duplicated business logic, including where sharing code helped and where it did not.
Confidence should not erase your personality. The proposal should still sound like you.
Marcin Mycek. Product Manager, Kotlin Build Tools
Stay true to yourself! It is important to make sure that your submission can be understood by others. A great practice is to give it to a few people you trust and ask what they understood from it and how it made them feel. However, keep your soul in it. A lot of great talks are quirky, do not follow every best practice, and people are there for it.
Advice and templates can help you organize your thoughts, but they shouldn’t make every proposal sound identical. Your perspective, language, humor, and enthusiasm are part of what makes the submission memorable.
Show reviewers how you communicate
Examples of previous talks help reviewers understand your presentation style and energy. If you have recordings from conferences, meetups, webinars, or livestreams, include the most relevant ones.
If you’re a first-time speaker and don’t have a formal recording, you can record yourself explaining part of the proposed talk. A simple laptop recording is enough. It doesn’t need professional lighting, editing, or production.
Svetlana Isakova. Team Lead in Kotlin Developer Advocacy, KotlinConf Program Committee member, and KotlinConf speaker
Examples of your talks help us make better choices. If you’re a first-time speaker and don’t have recordings, no worries! You can simply record yourself (even just part of your proposed talk) on your laptop and share the link. We would really appreciate it.
Depending on the topic, you can also include:
- A technical article
- An open-source project
- Documentation you have written
- A short technical demonstration
- A podcast or meetup appearance
- Other work connected to the proposed session
These materials support your proposal, but they don’t replace a clear title, abstract, and set of takeaways. Reviewers should still be able to understand the session from the submission itself.
Choose the format that fits the idea
Not every subject needs a full-length session.
A focused lesson, experiment, side project, or surprising discovery may work better as a lightning talk. A subject that involves significant technical context, several connected lessons, or a detailed demonstration may require a regular session.
Choose the format according to the amount of meaningful material you have. If you need to repeat yourself or add unnecessary content to fill a regular session, consider proposing a lightning talk instead.
Márton Braun. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker
X, , LinkedIn
Don’t forget that we also accept lightning talks! If you feel like your content would have to be padded to fill a regular session, it might be more enjoyable as a lightning talk.
You can also submit more than one proposal if you have several distinct ideas. Each submission should have its own story, audience, and takeaways rather than being a minor variation of another proposal.
Pamela Hill-Galloway. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker
X, , LinkedIn
Submit more than one talk! It gives you more chances to join in on the KotlinConf fun.
Review the proposal before submitting
Once you have completed your draft, step away from it and return later from the perspective of someone encountering the idea for the first time.
Check whether your proposal answers the following questions:
- Can someone understand the subject from the title?
- Is the connection to Kotlin clear?
- Does the abstract identify a real problem, question, or story?
- Is it clear who the session is for?
- Are the takeaways concrete?
- Does the proposal explain what makes your perspective different?
- Is the scope realistic for the selected format?
- Does the writing sound confident and authentic?
- Have you checked the spelling, grammar, links, and formatting?
- Does the proposal sound like the person who will deliver the talk?
Ask someone else to review it, too. Rather than simply asking whether they like it, ask them to describe what they think the talk will cover and what they expect to learn. Their answer will show whether the proposal communicates what you intended.
Chantal Loncle. Software Developer, Exposed, JetBrains
Double-check that the intended audience level aligns with the description and expected takeaways. Review the proposal from the perspective of someone you hope will be in the audience. Does it make sense as it is, or is it missing context that may be obvious to you but not to the reviewer or the future audience they are keeping in mind?
AI tools may help you check grammar or organize your thoughts, but the final proposal should reflect your own experience, ideas, and voice. A polished abstract without specific or authentic insight won’t be as convincing as one that clearly represents the speaker behind it.
Márton Braun. Developer Advocate, KotlinConf Program Committee member, and KotlinConf speaker
X, , LinkedIn
Your submission should show that you’ve put some thought and energy into preparing it. Check your submission for formatting issues and typos, and please don’t submit abstracts that were generated by LLMs.
Your Kotlin story could take the stage
You don’t need to know everything about Kotlin or have years of conference experience to submit a proposal. You need a useful story, an understanding of who it can help, and a clear explanation of why it matters.
Not every strong proposal can be selected. Conference programs must balance subjects, formats, experience levels, and audience interests. If your submission is not accepted, continue refining the idea, sharing your knowledge, and looking for other opportunities to present it.
Your experience might be exactly what another Kotlin developer needs to hear.
The KotlinConf 2027 Call for Papers is open! Share your experience, ideas, and Kotlin expertise with the community in Kraków.
Submit your proposal
