How to organize a hackathon for your internal developer portal

May 27, 2024

How to organize a hackathon for your internal developer portal

Ready to start?

You’ve chosen an internal developer portal. Now what?

You just chose an internal developer portal. You want to move ahead with your internal developer portal but you want to:

  • engage your stakeholders so that you can drive adoption.
  • showcase how the portal will benefit your users.
  • involve your users in the process of building it.
  • choose the right user stories for the portal MVP and define your future roadmap.

What we’ve seen as a solution is running a portal hackathon right at the beginning of the journey. It’s the perfect initiative for this; hackathons have the ability to bring the stakeholders together like nothing else. And we’re seeing first-hand how many organizations are taking the initiative and setting up their own portal hackathons. 

Since the hackathon requires some portal/platform knowledge we usually see platform teams leading it, but they involve the other stakeholders (developers, devsecops, finops) in some of the teams or in the evaluation or ideation process.

We’ve seen hackathons created specifically for:

  • A scoping exercise for the portal
  • Presenting different use cases of the portal to developers to get their thoughts
  • Focusing on individual use cases for the portal in teams
  • Working on a specific integration for the portal (in one really interesting case, an organization connected Port with their GPT-like tool to query Port’s catalog in natural language!).

Get the most out of your portal hackathon

Different hackathons may have similar objectives, planning processes and stages, but you may need to make yours fit an internal developer portal. That’s why we’ve put together this list of tips for creating a portal hackathon:

1. The hackathon is about developers, not platform engineers

When planning a portal hackathon, make it clear that the event is all about improving developer  work lives. Define what the issues are (eg. too many tools and too much context switching). Encourage participants to think about the frustrations developers face and what portal features could make their jobs easier; not what would make devops lives easier. 

Get developers to join using fun slogans like "This Hackathon is All About You" to show that their ideas and needs are the focus. This way, developers will feel more motivated to participate and come up with great solutions to enhance their daily work.

Consider sharing observations about developer needs - from surveys, interviews and more. You can even define types of solutions you’re looking for - the hackathon doesn’t have to be a free-for-all.

2. Learn from brainstorming principles

Go in with the mindset that all ideas are good - this way you can open your mind to the many options that portals present.

3. Clarity is key

Another important tip for your hackathon is to ensure that all participants are familiar with the developer portal and its four main pillars, which they can use to build new features. Consider organizing a brief training session or providing some reading materials ahead of the event.

These pillars include:

  • Software Catalog - significantly improves discoverability and visibility of all services and resources
  • Self-service actions - enables developers to self-service what is done today through a ticket or other interface (such as Jenkins) and contains golden paths and guardrails
  • Scorecards - to set and track compliance with standards
  • Automations - to eliminate repetitive, manual work

What the business objectives and (perhaps most importantly) how the portal will benefit them.

It’s worth remembering that developers may not necessarily engage with the business objective of “improving developer experience” or “boosting developer productivity”, nor will they necessarily care if you are reducing the number of tickets that they need to file. But, they will care about being able to do things like scaffold a new microservice, provision a new cloud resource, or find out information about multiple services without having to context-switch. In other words, when you’re presenting developers with the portal and its features, make sure you show them what it means for them. 

4. Provide access to the documentation

On the last point, there’s no better way to provide clarity than to give your developers access to the relevant documentation.

They can then get a better idea of what building the portal is likely to entail, as well as the myriad of possibilities it enables.

(You can find Port’s documentation here.)

5. Call in portal experts

It’s not enough to just present your ideas; you need to be prepared to answer a range of different questions - and sometimes you may not have all of the answers. Getting a portal expert to support the team can be helpful. Our customer success and solution engineer teams have been asked to support in the past, and you can feel free to request some help from them. 

You can also have the team check out Port’s open demo to get ideas about what solutions can look like.

6. Working on user stories are vital

Defining exactly what user stories (or use cases) consist of, is a great hackathon exercise. It could be around API management, AppSec, or Kubernetes, for example.  

We’ve had an organization that held a portal hackathon where they split the platform team in three smaller sub-teams, and each worked on one user story for 24 hours. What they achieved in such a short time frame was incredibly impressive.

Here are some specific guidelines for this tip:

Plan ahead

It’s worth considering building a minimal viable product (MVP) first. That means first defining what would go into the MVP and what should come after that. If you need help getting started, check out this blog.

And if you’re looking for inspiration for use cases and want a template for your roadmap, you can use our roadmap planner, which can be used to identify and prioritize user stories, and build a roadmap which can then be shared with stakeholders.

Consider how the portal’s pillars could benefit your use case

For example, if they wanted to implement just in time permissions, they could create a self-service action to get permission for access to cloud resources that auto terminate. They could also create a catalog of all the permissions given, to provide visibility, and automations to automate the permissions process for on-call engineers. 

Link your use case to your objective

User stories should factor in the overall objective and the metrics that can help you to achieve that objective. For instance, your use case could be to ‘get JIT permissions to production’, which links to the quantifiable metric of ‘improving incident response time’, which links to the overall objective of enhancing security and compliance. In short, your use case has to have the end goal in mind. 

7. Teams should be heterogeneous 

Make it a requirement that the teams for your hackathon include a mix of personas. Ideally, you’ll want developers, DevOps (or platform), product, DevSecOps, FinOps and more.

8. Don’t underestimate the power of prizes

Your teams are likely to be more competitive than you think. Competitiveness breeds competence; by offering prizes for the best ideas, you’re likely to benefit from a better portal. Implementing the best feature ideas is a great prize in itself for your developers, and should fill them with a sense of pride (but you should give them a separate prize, too!). 

9. Make some noise about your hackathon

Before and after your hackathon, make sure everyone that needs to know about it is aware. Ask your internal comms team to talk about it in the newsletter, put up flyers in the office, make a Slack channel for it - whatever works best to gain traction inside your company. Once the hackathon is over, use similar tactics to ensure you make noise about the key takeaways, the next steps, and the prize winners. 

10. Get feedback to make your next hackathon even better

Perhaps your first portal hackathon is focused on scoping your portal, and your next is about your MVP, a specific use case or integration. Get feedback from your participants on what they think worked with the hackathon and how the next hackathon could be improved. You can do this at the end of the hackathon or as an (anonymous) online survey.

11. Most importantly - make it fun!

This isn’t just any day of work. Keep your participants engaged throughout by making it fun. The prizes will help you to do this. You should also break up the day with different activities. Provide snacks, pizzas, drinks or coffees for the whole team. Perhaps you can keep a scoreboard to keep track of individuals/teams for all your hackathons. 

Hosting a hackathon can be a game-changer. It not only raises awareness among stakeholders about the portal but also helps them fully grasp its potential. Watch as adoption rates soar and excitement builds, transforming how developers interact with your platform.

Have you run a portal hackathon? Tell us about it here! Or discuss it with others who are in the same boat by joining our Community

{{cta_1}}

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

{{cta_2}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_3}}

Open a free Port account. No credit card required

Let’s start
{{cta_4}}

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start
{{cta_5}}

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start
{{cta_6}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_7}}

Open a free Port account. No credit card required

Let’s start
{{cta_8}}

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start
{{cta-demo}}
{{reading-box-backstage-vs-port}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

Microservices SDLC

  • Scaffold a new microservice

  • Deploy (canary or blue-green)

  • Feature flagging

  • Revert

  • Lock deployments

  • Add Secret

  • Force merge pull request (skip tests on crises)

  • Add environment variable to service

  • Add IaC to the service

  • Upgrade package version

Development environments

  • Spin up a developer environment for 5 days

  • ETL mock data to environment

  • Invite developer to the environment

  • Extend TTL by 3 days

Cloud resources

  • Provision a cloud resource

  • Modify a cloud resource

  • Get permissions to access cloud resource

SRE actions

  • Update pod count

  • Update auto-scaling group

  • Execute incident response runbook automation

Data Engineering

  • Add / Remove / Update Column to table

  • Run Airflow DAG

  • Duplicate table

Backoffice

  • Change customer configuration

  • Update customer software version

  • Upgrade - Downgrade plan tier

  • Create - Delete customer

Machine learning actions

  • Train model

  • Pre-process dataset

  • Deploy

  • A/B testing traffic route

  • Revert

  • Spin up remote Jupyter notebook

{{tabel-2}}

Engineering tools

  • Observability

  • Tasks management

  • CI/CD

  • On-Call management

  • Troubleshooting tools

  • DevSecOps

  • Runbooks

Infrastructure

  • Cloud Resources

  • K8S

  • Containers & Serverless

  • IaC

  • Databases

  • Environments

  • Regions

Software and more

  • Microservices

  • Docker Images

  • Docs

  • APIs

  • 3rd parties

  • Runbooks

  • Cron jobs

Starting with Port is simple, fast and free.

Let’s start