General

Intro to DevRel: What's the Difference Between External and Internal DevRel Programs?

Published Nov 22, 2023

Updated Nov 22, 2023

5 min read

Developer Relations (DevRel) is a proactive, multifaceted discipline that bridges the gap between developers and companies to drive adoption while cultivating an energetic and supportive developer community for their product, service, or technology.

The term and the profession are often misunderstood even among those in other technical roles. Some have never heard of DevRel before, and others believe it’s a kind of tech support for developers. Many organizations even think starting a DevRel program means just giving away free software and hoping it catches on. But DevRel is none of these things.

At its core, a successful DevRel program builds strong bonds within their target market to ensure that developers can interface with a company or organization behind the product they’re using. Great teams establish authentic connections with developers, cultivate trust, and actively engage with them.

DevRel defies traditional marketing strategies. Instead of prioritizing numbers and eyes that contribute to a sales funnel, it focuses on enhancing developer satisfaction. This creates a feedback loop between users and a company to better meet their needs, and foster a sense of collaboration within a product’s user community.

The Two Main Domains of Developer Relations

DevRel is split into 2 main domains: external and internal.

External: Accessing an existing developer community

If a company already has a product with an existing community or a product that may appeal to an existing community, and they want to establish a DevRel program around it, this would fall within the external domain.

A successful external program will establish credibility and support developers through a number of evangelistic measures like blog posts, tutorials, webinars, giving talks at meetups and conferences, or creating useful code examples to teach concepts.

These activities and their goals are rarely product-specific. Instead, they incorporate a number of technologies within their product’s technical ecosystem to demonstrate its value to a developer’s workflow.

I had the pleasure of working with Doron Sherman during his tenure at Cloudinary as VP of Developer Relations. Doron has extensive experience with building developer communities, and successfully advocated internally to build a website called Media Jams, a learning resource for developers working with media in their apps.

By having this initiative live under Developer Relations, and not under Product, Marketing, or Engineering, Doron and his team built quickly and created a site that prioritized education, without needing to meet the business objectives of other parts of the organization.

“Media Jams has had great organic growth as a community resource. We were able to attract non-Cloudinary users as well as organic search traffic of those looking for media use cases who would have otherwise gotten lost in the Cloudinary docs and/or could not find help through the Cloudinary blog or knowledge base.” says Doron.

Internal: Building a developer community

In order to support the adoption and retention of developers using a product, companies must have a space where developers can interface with them. Building their own community around a product is the best way to do this.

By creating open lines of communication, developers can provide immediate feedback about a product in a productive way to product and engineering teams thereby shortening the feedback loop and improving the speed at which a team is able to innovate based on user needs. This strategy falls under the internal domain.

These forums also provide synergistic opportunities for developers that are using a product to learn from each other. By working on similar problems, developers are able to bond and feel more ownership or excitement toward a product, increasing user retention.

Danny Thompson, a developer influencer and mentor who has built a community of over a quarter million followers, says that he admires Appwrite’s DevRel program, helmed by Tessa Mero, Head of Developer Relations:

“The Appwrite DevRel team is great at answering questions. They are on Discord, jumping on calls with developers, answering questions, and doing office hours, all of which are super valuable in building that community. The main difference between Appwrite DevRel and other teams is, a lot of communities are run very passively and not always available or taking an active approach within community forums to help out.” - Danny Thompson on Appwrite.

“When we think about how to become successful as a company through DevRel, our first consideration is, what made us successful in the first place? Appwrite became an open-source company and a successful open-source project because of community, so we focus on a community-first approach. Contributors and developers that have supported us since before we were a company are what led us to where we are now. Every initiative, every planning, and everything we do on our team, we consider the community's feedback and perspective before we make any decisions.” - Tessa Mero at Appwrite.

The Value-First Approach to Developer Relations

Successful DevRel programs prioritize delivering value to cultivate credibility among developers and support product adoption free from reciprocal demands. External efforts involve engaging with existing technology communities, establishing credibility through various evangelistic measures, and delivering value to the community. On the other hand, internal programs build communities around their product, facilitating direct communication between developers and the company. These internal forums not only enhance user retention but also foster a space for developers to learn from each other, creating a sense of ownership and excitement around the product. And by diverting equity to these two programs, DevRel teams find new users, retain them, and receive invaluable feedback.

Real-world examples, such as Doron Sherman's work at Cloudinary and Tessa Mero's leadership at Appwrite, showcase the effectiveness of DevRel in action, and highlight how DevRel programs contribute to the success and sustainability of developer-focused products.

In the ever-evolving landscape of technology, DevRel emerges not only as a bridge between developers and organizations, but as a crucial driver of innovation, ensuring products remain relevant, adaptive, and deeply integrated into the communities they serve.

If you’re thinking about building a successful DevRel program for the first time, the best place to start is to reflect on some of your favorite brands and how they connect with the developer community. Do they simply distribute discount codes and free swag, or are they reaching out to their users, and providing them a platform to learn, collaborate with others, and contribute? If they are, what methods do they use, and how do those methods coincide with your team’s existing strengths?

And if you ever have any questions or want to connect with a DevRel specialist, do not hesitate to reach out!

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Tracy Lee
Partner, This Dot Google Developer Expert (Angular, TC39, Web) RxJS Core Team & Lead for RxJS Learning Team Contributor to Angular, RxJS, EmberJS

Key Strengths:
- Teaching developer relations strategies
- Influencer marketing
- Developing brands
- Community strategies and maintenance
- Creating product launch strategies
- Leading marketing operations efforts & standards
- Effective conference presence & speaking strategies
@ladyleet @ladyleet

9 Essential Mental Models in Developer Relations

Developer Relations (DevRel) is the glue that bonds developers and organizations. Successful DevRel professionals become experts in fostering community, which benefits both developers and organizations, and drives positive outcomes for all stakeholders involved. Below is a list of mental models often employed by DevRel experts. Which one speaks most to how would you approach developer relations? 1. The Empathy Circle Empathy is a cornerstone of DevRel. Understanding and sharing the feelings, thoughts, and perspectives of developers is crucial to building trust and strong relationships. The Empathy Circle is a mental model that reminds DevRel professionals to actively listen, ask open-ended questions, and practice radical empathy to gain deep insights into developers' experiences. 2. The Pareto Principle (80/20 Rule) The Pareto Principle, often called the 80/20 rule, suggests that roughly 80% of results come from 20% of the causes. In DevRel, this can be used to identify which developers or communities have the most significant impact on your products. By focusing efforts on the most influential groups, DevRel professionals can maximize their effectiveness. 3. Inversion Inversion is a mental model that encourages thinking in reverse. Instead of asking, "How can we get more developers to use our product?" DevRel professionals might ask, "What could make developers NOT use our product?" This approach helps identify potential roadblocks, allowing DevRel teams to proactively address issues and improve the developer experience. 4. The Ladder of Abstraction The Ladder of Abstraction, introduced by Bret Victor, is a mental model that helps DevRel professionals communicate effectively. It suggests that information can be presented at various levels of abstraction, from concrete to abstract. Understanding where a developer is on this ladder can help you tailor your messaging to their specific needs and expertise level. 5. The Innovation Adoption Curve (Rogers Adoption Curve) The Innovation Adoption Curve, also known as the Rogers Adoption Curve, classifies users into categories like innovators, early adopters, early majority, late majority, and laggards. DevRel professionals can use this model to identify where different developers fall on the adoption spectrum and tailor their strategies to meet the unique needs and concerns of each group. 6. The Hype Cycle The Hype Cycle, developed by Gartner, describes the stages that new technologies go through, from the "Innovation Trigger" to the "Plateau of Productivity." DevRel professionals can use this model to understand where their products or technologies are on the curve, and adjust their messaging and strategies accordingly. 7. The Feedback Loop Feedback is crucial for improvement. DevRel professionals should view feedback as a gift and a source of valuable information. The Feedback Loop mental model reminds them to actively seek, process, and act on feedback from developers, whether it's positive or constructive criticism. 8. The 10x Developer Myth The 10x Developer Myth is a cautionary mental model that encourages DevRel professionals to recognize that not all developers are equally productive. Treating all developers as if they're the same can lead to misunderstandings and frustration. Instead, acknowledge the diverse range of skills and experiences within the developer community. 9. The Trojan Horse Model The Trojan Horse Model encourages DevRel professionals to find creative ways to introduce their products and ideas to developers without making it feel like a sales pitch. By creating value and solving real problems for developers, you can gain their trust and loyalty over time. Conclusion DevRel professionals play a crucial role in bridging the gap between developers and the products they use. To excel in this field, adopting these mental models can be transformative. By fostering empathy, leveraging the Pareto Principle, and using other models, DevRel professionals can navigate the complexities of their roles and make a lasting impact on the developer community and their organizations. Remember, the mental models are tools, and how they are applied makes all the difference in creating meaningful connections and driving success in Developer Relations! Best of luck to you, and please do not hesitate to contact me if you have any questions about introducing a successful DevRel program in your organization....

Jan 31, 2024

3 mins

DevRel

Intro to DevRel: 5 Reasons Why DevRel Teams Fail

Although Developer Relations (DevRel) defies traditional marketing strategies, prioritizing enhancing developer satisfaction ahead of promoting numbers that contribute to a sales funnel, it is still possible for DevRel teams to fail at delivering desired business objectives. And unfortunately, more often than not, this leads to the dissolution of DevRel efforts, and sometimes even role elimination. Below, I’ve compiled a list of five of the top reasons why DevRel teams fail. 1. Lack of Leadership Buy-In DevRel requires buy-in and support from executives and stakeholders within the company. Without buy-in, being able to work cross-functionally across the organization, get access to data needed for measuring success, have the ability to influence change within the organization, or get the budget for necessary activities to engage developers will be impossible. I asked Jason Lengstorf, the host and founder of Learn With Jason and previously on the Developer Relations team at Netlify and Gatsby, where he has seen companies fail at DevRel before: “Companies that want to invest in DevRel can collect as many well-known developers as they can, but giving them zero dollars and zero autonomy will force teams to rage quit or become content farms because that’s all you can do with no budget.” Other examples are departments not willing to share or give data that helps enable DevRel to understand the metrics they need to effectively baseline and track the success of their efforts. By not doing so, the DevRel team will not be able to justify their work to leadership, which will lead to those positions being cut first when budget cuts come around. Chris Woodruff, Founder of Advocatus, a Developer Relations consultancy, says “DevRel is seeing a lot of layoffs. It’s the easiest team for management to let go because they don’t fully understand the ROI and metrics. These are the holy grails of DevRel, and because they do not understand, they will always be the first teams to let go if management can’t see the actual return or how it affects the bottom line.” 2. Company Culture Fit If an organization's culture does not value collaboration and resists the presence of a DevRel team, DevRel will not be able to effectively advocate for developers or help teams be more successful with their target audience. Francesco Tisiot, Senior Developer Advocate at Aiven, an open-source data platform that makes setting up cloud databases simple, shared one of his experiences in his Developer Relations career. “I was one of the first DevRel hires in a company and we were in the marketing organization. Initially, there was pushback from engineering and product teams on our product feedback and feature requests since we weren't seen as experts. But, DevRel is about breaking barriers and building bridges, so, in leading by example, we demonstrated our technical knowledge and now have a strong impact on all the teams.” Michael Liendo, Senior Developer Advocate at AWS, an online platform by Amazon that provides scalable and cost-effective cloud computing solutions, shared how he was able to find the company culture fit within organizations he has served in the past. Being in a position of Developer Advocacy, and quite literally trying to advocate for developers that use the platform, he says, “Some of the biggest challenges for DevRel are actually internal. Engineers at many companies often focus on one piece of the product. As they're testing features, they may be creating workarounds without realizing they're workarounds. This means they often miss what a proper Developer Experience flow looks like. I've had to push for them to include me in design meetings, and get them to understand that I'm the Lorax--I speak for the community! A phrase I have been known to say is ‘this solves the problem, but it's not a solution’. I'm known for having a high bar for what is considered ‘good enough’ and though the end result is accumulated trust, it's a challenge to get there.” 3. Operating in Isolation DevRel cannot operate in isolation without integration with development, marketing, product teams, sales, or a subset of these. The team will struggle to make a significant impact. DevRel requires a collaborative approach and alignment and synergy with other teams. Francesco Ciulla, Developer Advocate at daily.dev, a professional network for developers that provides the latest tech news and articles, shares his thoughts on how DevRel organizations can be successful within larger organizations: “DevRel organizations can thrive within larger organizations by establishing clear communication channels and fostering meaningful collaborations. They must align their objectives with the company's goals and illustrate their value by sharing tangible outcomes from developer engagement.” 4. Lack of Strategy Proceeding into DevRel without a clear strategy will make it difficult for a DevRel team to establish its purpose within an organization and set priorities that will make an impact. There will not be a clear vision the team can drive towards, leading to wasted efforts and the inability to produce tangible outcomes. If DevRel does not have any goals set, they can only do their best to assume what efforts they should invest in to provide value to the organization. Worst yet, if they do not have any goals set, they may not choose to focus on providing value to the organization, but to a community that the organization has no interest in. Many DevRel experts have seen this happen time and time again in the community, and are always left scratching our heads. Many times, the “strategy” for an organization is to hire DevRel, but that is where the strategy stops. Decision-makers want DevRel professionals to come in and just “do what they do best”. Unfortunately, when decision-makers say this, they typically have an idea of what outcomes they want DevRel to drive, but don’t want to share those thoughts because they feel like DevRel professionals should know what to do. Expectations left open to interpretation often lead to a poor impression of the performance of the DevRel team by decision-makers, and those teams are never able to establish a sense of trust or direction within that organization. Jeremy Meiss, former Director of Developer Relations at CircleCI, says, “One of the biggest problems we have seen in this industry is the startups that were counseled by their VC, founders, or board that they need a DevRel team because the other similar companies had one and it was great for them. They push for it, and one of the early hires is DevRel. Generally, that DevRel hire is someone relatively new in the industry, so you can coax them to start at a new company without clear goals or objectives. New hires like this come in without a lot of experience in the field of DevRel and have not experienced it at different levels of companies. They are heavily pushed by marketing, the CEO, the CTO, and other departments into thinking DevRel should look a certain way, but don’t have the foundational knowledge to be able to push back because they are not yet in this area.” Jeremy’s illustrative explanation of why a lack of strategy ultimately results in the failure of a DevRel team within an organization is one that is common across many devtool startups that have popped up in recent years. 5. Lack of Metrics and Reporting A well-rounded set of DevRel metrics typically comes from multiple areas of the organization, whether that be marketing, sales, product, customer success, or customer support. Without free access to cross-functional team data, it is difficult to show the value and ROI of DevRel. Establishing a baseline set of metrics if you’re new within an organization, or understanding the baseline metrics that currently exist is critical in ensuring the success of your job in DevRel. Tessa Mero, Head of Developer Relations at Appwrite, has a very specific set of metrics her team focuses on. She shared a few of those metrics: - Growth of our GitHub Repo (stars) - Growth of our Discord Community - Improved engagement in Discord community - Growth of our Twitter followers and engagement - Growth of our Appwrite Cloud developers - Number of views or impressions on any video and written content, whether it's internal or externally created - Amount of content created weekly (written or video) - Number of projects created with Appwrite for Hackathon sponsorships - Number of attendees / questions at a conference talk - Number of connections at conferences - Number of community support questions answered, improving rate of responses AND rate of how fast we respond, in all public forums - Number of support tickets responded to - Number of community feedback taken and moved into our DX/Product discussions - Number of feedback from UI/UX perspectives and working with design team to follow up with the devs/users with what we did with the feedback - Number of engagement/activity from our Appwrite heroes/ambassadors This is just one example of and a subset of metrics a DevRel team should consider tracking, but what you track and how you track it is dependent on your goals and the product. Metrics and what your leadership considers a good ROI can vary greatly from organization to organization. I spoke to another Developer Relations expert in the industry and she shared her experience with the company she just left and the reason she left - and it was focused around metrics. She was initially interested in joining the team because of the lack of metrics. However, over time, as she got more experience and as she became more visible, her workload became difficult to prioritize. Since there were no metrics, there were no objectives to measure against to say what was good and what was bad. She felt like she didn’t know what she was doing well or not doing well. Once metrics began to be implemented, the company started pushing her to do more, and she had nothing to push back with because the high-level goals were not there. There was no way to prioritize the workload. The company started tracking things like page hits, unique visitors, unique views of videos, number of subscribers, activity on twitter, and other similar numbers, but it was hard to tie any of these back to the ROI for the company. How do you quantify and determine if 100 new subscribers on YouTube is better than 100 new subscribers on twitter? If you can’t quantify it, how do you prioritize it? What Successful DevRel Teams Do Differently With the nature of DevRel and the multitude of levers and factors that determine success and failure, it’s important to allow space for a team or set of individuals to experiment and iterate before making judgment calls. One company that serves millions of developers on its platform is starting up a new meetup program and testing the ROI of sponsoring meetups around the world. Since they are in the testing and experimentation phase, they don’t yet know how to measure success, and that is clear to leadership. The current strategy is sponsoring local meetups for a few months and seeing what the result is. Why are they so seemingly laid back in their approach? Is it the right approach? The reason for the relaxed nature of the testing phase is that they don’t want to be pushy to the meetup organizer to find something out or measure something. They are not expecting anything, but will evaluate what metrics they could use to establish success criteria. This approach is a thoughtful and empathetic one, and clearly, the DevRel team has an understanding of how to approach community members in a way that will not turn them off. Internally, the simple numbers they are looking at are the number of RSVPs, the number of attendees that show up, and the difference between the two. DevRel is naturally iterative and requires a team to experiment, test, and refine their strategies. Effectively engaging developers is not black and white, and a strategy that works for one community or company may not necessarily work for another. Furthermore, building domain expertise and gaining a deep understanding of the developer community they serve takes time. Experimentation and iteration help teams refine their knowledge, identify patterns, and develop strategies that resonate with developers. This expertise becomes an asset in driving long-term success. It’s also important to acknowledge that building domain expertise within a segment as well as building relationships and trust with developers in that segment takes time. The technology landscape changes quickly and new technologies are being released weekly. Developer sentiment is fickle and changes just as quickly regarding favored approaches and products. That being said, the above pitfalls remain common causes for DevRel teams to fail, and by remaining mindful of and vigilant against them, DevRel teams both new and old can succeed in supporting key business objectives like developer retention, community growth, and product development....

Feb 14, 2024

9 mins

DevRel

This is the Worst Thing a DevRel Team Could Do

At its core, a successful Developer Relations (DevRel) program focuses on forming strong connections within its target audience to ensure that developers can easily connect with the company or organization behind the product they’re using. Great teams in DevRel build genuine relationships, earn trust, and actively engage with developers. DevRel takes a different approach from traditional marketing strategies. Instead of just chasing numbers and leads for sales, it puts emphasis on making developers happy and retention. This creates a cycle of feedback between users and a company, helping to better understand their needs and fostering a sense of community among users. There have been organizations that consider DevRel a revenue-driving function, but this is where challenges arise, since DevRel teams cannot consistently show value in this area and meet the expectations of stakeholders expecting this based on where their focus and the profession lies. When DevRel professionals are forced to be revenue drivers, the breakdown between developers and that company is inevitable. Developers can smell hidden agendas from a mile away. They realize when their needs are being overlooked in favor of sales initiatives. *“Companies fail at DevRel when they try to turn them into sales teams. This hurts customer trust.” - Michael Liendo, Senior Developer Advocate at AWS. * Developers care about education, resources, opportunities, and the overall experience of a product or platform. When they are a target for sales pitches, they leave or shut down. Their focus is getting the job done, and they talk to companies to solve problems in their development lifecycle, not to be on the receiving end of a pitch. Furthermore, since all successful DevRel teams are focused on building authentic relationships with developers, strategic partnerships with other organizations will be hard to come by or have dismal retention numbers since no one wants to be associated with trying to sell to developers. Good DevRel teams are focused on helping developers and understand that being helpful goes a long way to help the sales cycle. Many DevRel efforts also focus on providing value to a community before asking for something in return. The trust and authenticity of brand building in this area and those initiatives - the loyalty a DevRel team is trying to generate - many times does not make direct corollary sense from a monetary perspective, and sales organizations often overlook the non-monetary value and impact these efforts generate and how they correlate to long-term growth for an organization. In DevRel, genuine connections matter more than immediate revenue. When teams prioritize developers' needs over sales, trust grows, fostering lasting relationships that drive long-term success. Treating DevRel as solely a sales function erodes trust and misses the true value of building authentic partnerships and community loyalty. Interested in learning more about launching your own DevRel program, feel free to reach out!...

Mar 6, 2024

2 mins

DevRel

Svelte 5 is Here!

Svelte 5 was finally released after a long time in development. Fortunately, we've been able to test it for some time, and now it has a stable release. Let's dig into its features and why this is such a significant change, even though Svelte 4 code is almost 100% compatible. Svelte syntax everywhere This is one of my favorite additions. Previously, Svelte syntax was limited to a component element. Refactoring code from a component and moving it to a JavaScript file worked differently. Now you can use the .svelte.js or .svelte.ts extension, which allows you to use the same syntax everywhere. It's important to note that it's a way to express that this is not just JS, and what you write may be compiled to something else, just like .svelte files are not just html even though they look very similar. Runes The introduction of runes is one of the most significant changes in Svelte. Many users felt attracted to variables being instantly reactive in previous versions. ` There was, however, a lot of magic underneath and a considerable amount of work from the compiler to make it behave reactively. $state In Svelte 5, a reactive variable has to be explicitly declared using the $state rune, which brings a clear distinction between what is reactive and what isn’t. ` In the previous code, $state is not an actual function being called; it's a hint for the compiler to do something special with this declaration. Rune names always start with a dollar sign ($) and do not need to be imported. However, there’s much more to the changes than just the way we declare reactive variables. Runes bring a lot of new features that make Svelte 5 a great improvement. In Svelte 5, objects or arrays use Proxies to allow for granular reactivity, meaning that individual properties in an object are reactive, even if they are nested objects or arrays. If you modify a property, it will only update that property and will not trigger an update on the whole object. It also supports triggering updates when methods like array.push are called. In previous versions, an assignment was required to trigger an update: ` To have a similar behavior of svelte 4 (no deep reactivity), use the $state.raw() rune. This syntax of .* is common for related features of a rune: $state.raw() will require an assignment to trigger reactivity. ` Because proxies are used, you may need to extract the underlying state instead of the proxy itself. In that case, $state.snapshot() should be used: ` $derived We will use $derived and $derived.by to declare a derived state. The two runes are essentially the same, except one allows us to use a function instead of an expression, allowing for more complex operations to calculate the derived values. ` $effect Effects are useful for running something triggered by a change in state. One of the things you'll note from the $effect rune is that dependencies don't need to be explicit. Those will be picked from reactive values read synchronously in the body of the effect function. ` Something to bear in mind is that these dependencies are picked each time the effect runs. The values read during the last run become the dependencies of the effect. ` Depending on the result of the random method, foo or bar will stop being a dependency of the effect. You should place them outside the condition so they can trigger reruns of the effect. *Variants* of the effect rune are $effect.pre, which runs before a DOM update, and $effect.tracking(), which checks for the context of the effect (true for an effect inside an effect or in the template). $props This rune replaces the export let keywords used in previous versions to define a component's props. To use the $props syntax, we can consider it to return an object with all the properties a component receives. We can use JavaScript syntax to destructure it or use the rest property if we want to retrieve every property not explicitly destructured.. ` $bindable If you want to mutate a prop so that the change flows back to the parent, you can use the $bindable prop to make it work in both directions. A parent component can pass a value to a child component, and the child component is able to modify it, returning the data back to the parent component. ` $inspect The $inspect rune only works in dev mode and will track dependencies deeply. By default, it will call console.log with the provided argument whenever it detects a change. To change the underlying function, use $inspect.with().with): ` $host The host rune gives access to the host element when compiling as a custom element: ` ` Other changes Another important change is that component events are just props in Svelte 5, so you can destructure them using the $props() rune: ` A special children property can be used to project content into a component instead of using slots. Inside the components, use the [@render[(https://svelte.dev/docs/svelte/@render) tag to place them. ` Optional chaining (?.) prevents from attempting to render it if no children are passed in. If you need to render different components in different places (named slots before Svelte 5, you can pass them as any other prop, and use @render with them. Snippets Snippets allow us to declare markup slices and render them conveniently using the render tag (@render). They can take any number of arguments. ` Snippets can also be passed as props to other components. ` ` Conclusion Some exciting changes to the Svelte syntax were introduced while, at the same time, maximum compatibility efforts were made. This was a massive rewrite with numerous improvements in terms of performance, bundle size, and DX. Besides that, a new CLI has been released, making the whole experience of starting a project or adding features delightful. If you haven't tried Svelte before, it's a great time to try it now....

Nov 27, 2024

4 mins

Svelte

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Intro to DevRel: What's the Difference Between External and Internal DevRel Programs?

The Two Main Domains of Developer Relations

External: Accessing an existing developer community

Internal: Building a developer community

The Value-First Approach to Developer Relations

Tracy Lee

You might also like

9 Essential Mental Models in Developer Relations

Intro to DevRel: 5 Reasons Why DevRel Teams Fail

This is the Worst Thing a DevRel Team Could Do

Svelte 5 is Here!

Let's innovate together!

You might also like

9 Essential Mental Models in Developer Relations

Intro to DevRel: 5 Reasons Why DevRel Teams Fail

This is the Worst Thing a DevRel Team Could Do

Svelte 5 is Here!