++ +--- + +## Enabling the Frontend Chapter + +Of course, modernizing code is only half the story. To make the change sustainable, we had to modernize how frontend teams worked together. + +That’s why we invested heavily in **chapter enablement**, working side-by-side with internal engineers, not just handing over documentation. We ran brown-bag sessions on migration strategy and component design and paired regularly with developers across all teams to share context and unblock real issues in real time. The goal wasn’t just to teach patterns but rather to co-develop them in the flow of real work. + +We also helped define **foundational standards**: folder structures that made sense, a linting setup that teams could agree on, and a testing strategy that didn’t feel like a burden. Rather than enforcing anything from our side, we built these practices together with the people who would use them daily. + +And yes, we co-led the development of a **shared component library**: something simple, discoverable, and designed to scale. We set it up as a private package inside the existing monorepo to enable gradual adoption. We integrated it with **Storybook** for visual QA and smoother onboarding. Plus, we documented the contribution guidelines and changelogs to ensure it could be maintained effectively over time. + +Searchmetrics already had a component library in place, but we helped transform it into a central pillar of the migration by refactoring key UI elements and expanding it to support multiple teams working on an enterprise product suite. We worked within familiar patterns, which made adoption easier and reduced friction. + +Developers began using the improved library in new views almost immediately. It quickly became the go-to for building consistent interfaces, helping reduce **duplication** across the product. + ++ 💡 If you are interested in how we handle framework migrations, you can read about our experience migrating from Angular to React at sevdesk: + + “How We Migrated an Enterprise App from AngularJS to React Without Downtime” + . +
+
++ +At Mister Spex, the process looked somewhat different. We built a component library **from the ground up** to support a newly introduced design system. Working closely with engineers across product teams, we focused on making components truly reusable despite the challenges of distributed ownership and differing service architectures. + +Before this, duplication was commonplace: similar UI elements were implemented in slightly different ways across teams. The new library gave them a consistent foundation to build on, improving alignment and reducing rework. + +--- + +## Long-Term Impact + +By the end of the engagement, modern frameworks had become the norm, and the legacy systems had been fully phased out. Developers at Searchmetrics and Mister Spex were building faster and with fewer frustrations, using a shared component library that significantly improved efficiency, consistency, and ease of integration. With seamless alignment between design and code, teams were confidently shipping new features on a modern, unified foundation. + +Beyond just technical gains, the biggest shift was the momentum. Migration stopped feeling like a one-off project and became part of how the teams worked. The frontend chapters gained solid footing, the libraries continued to evolve, and the teams took real ownership of the systems they helped build. + +--- + +## What We Learned + +We’ve experienced firsthand that **zero-downtime migrations are possible**, but only if you approach them as more than just a technical problem. + +Here’s what worked for us: + +- **Don’t pause delivery.** Integrate migration into the roadmap for better quality and long-term stability. +- **Introduce team governance early.** A shared library is only as strong as the practices and people around it. +- **Build in layers.** Use hybrid patterns, wrapper bridges, and feature flags to avoid big-bang cutovers. +- **Embed in the team.** Real change happens when you’re part of the chapter, not an external advisor. + +--- + +Modernizing a large frontend doesn’t have to mean hitting pause on everything else. As we saw with Searchmetrics (now Conductor) and Mister Spex, migration works best when it's treated as a part of the regular product development. It should be tied to real features, built alongside the roadmap, and shaped through close collaboration with the teams doing the work. + +By co-developing a strategy tailored to the client’s needs, along with shared libraries, solid patterns, and internal support, teams are able to move beyond legacy code gradually, confidently, and without disruptions. + +If your team is facing a legacy migration, let’s talk! We’ll help you modernize without slowing down—one component at a time. \ No newline at end of file diff --git a/apps/website/src/content/posts/migrating-an-enterprise-app-from-angularjs-to-react.md b/apps/website/src/content/posts/migrating-an-enterprise-app-from-angularjs-to-react.md new file mode 100644 index 00000000..12ffe560 --- /dev/null +++ b/apps/website/src/content/posts/migrating-an-enterprise-app-from-angularjs-to-react.md @@ -0,0 +1,118 @@ +--- +title: "Migrating an Enterprise App from AngularJS to React" +description: "Discover how we helped sevdesk migrate from AngularJS to React with zero downtime or feature freezes. Learn how incremental refactoring, team enablement, and smart process alignment led to lasting success." +createdAt: 1754595192134 +updatedAt: 1754595192134 +authors: ["ante"] +category: "CASE STUDY" +editors: ["velimir"] +abstract: "Migrating a live product to a new framework isn’t just a technical challenge—it’s an organizational one. In this post, I share how we partnered with sevdesk to navigate the end of AngularJS support and transition their accounting software to React without downtime, feature freezes, or disrupting users. From introducing hybrid architectures to embedding knowledge transfer through workshops, pair programming, and team mentoring, we focused on enabling sevdesk’s developers to own the new codebase. This story highlights why successful migrations depend not only on clean code, but on shared ownership, developer motivation, and changes that stick long after the migration is done." +image: "/images/from-angular-to-react.png" +draft: false +--- + +Migrating from one framework to another is never a simple task, especially when it involves a live product used by thousands of customers. When a client reached out to us, they were facing the end of support for AngularJS and needed a plan to modernize their app without disrupting the user experience. This is the story of how we partnered with them to navigate a high-stakes migration to React, without downtime, feature freezes, or loss of momentum. + +## Contents + +## The client’s concerns + +Our client was **sevdesk**, a company that offers online accounting and invoicing software. It is trusted by over 130 000 companies and users to help manage finances, create invoices, track expenses, and handle accounting tasks without needing advanced accounting knowledge. + +Since the end of support for AngularJS/Angular 1.6, sevdesk faced a major turning point. Without new patches, AngularJS applications became exposed to increasing security risks, especially as new browser vulnerabilities emerged. This posed a serious problem since the app handles sensitive financial data. + +Most third-party libraries dropped support for AngularJS, meaning that developers would have to stop updating dependencies to avoid breaking changes or maintain their own forks. This may seem like a minor inconvenience, but outdated dependencies can lead to additional security issues. On the other hand, maintaining forked libraries adds extra complexity and a risk of future incompatibilities with other libraries. + +Another pressing issue was the shift in the developer landscape, as knowledge of AngularJS became a *legacy skill*. Finding new developers became more difficult, raising concerns about long-term maintainability and limiting the growth of the company. + +Considering the risks of continuing with AngularJS, sevdesk decided that the migration was crucial for the future of the company and chose to adopt React instead of Angular due to its long-term advantages. Since their development team lacked experience working with React and was facing significant changes to both the product and the company, sevdesk reached out to us to help execute this large-scale migration as smoothly as possible. + +## Migration Risks and the Importance of Knowledge Transfer + +Poorly planned migration strategies can introduce significant risks. It's important to recognize that few organizations have the luxury of completely stopping application development during a migration. Long feature freezes are rarely feasible, so successful migrations must be designed to occur incrementally and with minimal disruption to ongoing development. + +On the other hand, dividing internal resources into separate teams for maintenance and migration can stretch capacity thin, leading to slower progress on both fronts. While involving external teams may seem efficient, it can result in a disconnect between those maintaining the current system and those executing the migration. More critically, if the migration is heavily reliant upon an external team without adequate knowledge transfer, the internal team may struggle to maintain and update the new system once the external team departs. In the worst-case scenario, this leads to wasted time and resources, and a product that is harder to support than the one it replaced. + +To ensure sevdesk avoided these risks, we worked hand-in-hand with their developers to execute the migration in a way that safeguarded development stability and ensured future maintainability. + +## Our goals and requirements + +Since our end goal was to ensure that the development team is equipped to maintain the app well into the future, we knew that simply delivering the migration wasn’t enough. That’s why we made knowledge transfer one of our top priorities. + +In order to minimize disruption, we needed a clear understanding of the requirements and the development team's workflow. To gain this insight and fully grasp the motivation behind the migration, we began with an introductory period to familiarize ourselves with the project and the developers. + +Additionally, the app needed to remain fully operational, with zero downtime, as something like that could lead to a negative user experience and potential client loss. To make things even more challenging, there would be no feature freeze, meaning feature development would continue alongside the migration process. This was something that impacted our decision regarding the migration strategy because there was a potential risk that the development team could get overwhelmed trying to keep up with everything. + +## Our approach + +We see ourselves as the client’s teammates, partners even, and not just outsiders. We integrate into the client’s process with care and attention to their existing ways of working. We aim to be as involved as possible by familiarizing ourselves with their development team’s domain and working methods. By reviewing their roadmap, we gain insight into upcoming changes and features, ensuring we remain up to date with the status of the project. + +We participate in their retrospectives and planning sessions to ensure alignment and effective preparation for upcoming tasks. We also actively communicate with their developers, providing support and guidance in implementing new features and in future planning. On the technical side, we take significant measures to ensure that feature development and migration work happen on the same codebase, preventing divergences and minimizing integration risks. This helps us maintain a positive and productive collaboration with both the developers and all other project stakeholders. + +When it comes to sharing knowledge, we recognize that not everyone learns at a fixed pace. We present the developers with multiple approaches and encourage them to engage with the ones they find most helpful, including workshops, group coding sessions, and pair programming. + +Whenever we are tasked with large codebase initiatives, we are always on the lookout for developers who are eager to learn and collaborate, as their motivation and involvement are essential for driving successful migrations and ensuring that the resulting systems remain maintainable long after our work is done. + +By fostering this kind of mutual trust and continuous learning, we leave teams better equipped to evolve confidently even after our engagement has ended. + +## Getting to Know the teams + +At the time, sevdesk developers were divided into smaller teams and everyone had a clear sense of ownership over their respective domains within the app. We met with every team to gain a better understanding of their domain, the upcoming features they were responsible for implementing, and how we could best support them. However, the complexity of the migration introduced coordination challenges that could not be fully addressed within the existing team structure. To address this without disrupting the development team, we proposed the creation of a new team dedicated to the migration and all React-related tasks—the Core team. The Core team consisted of two developers from CroCoder and additional developers assigned by sevdesk to help with the migration. + +## How We Drove the Outcome + +### Handling Feature Development During the Migration + +Our development started with creating a new component library and rewriting old AngularJS components in React. Since there was no feature freeze, other developers continued adding new features to the app while we simultaneously rewrote the components. The addition of new features required new components, but adding them to the existing Angular component library didn’t make sense, as it would result in unnecessary code that would ultimately be replaced later. That is why we came up with a solution that would allow the developers to continue adding new features in the Angular app and use the new React components at the same time. Enter the Angular Wrapper. + +The Angular Wrapper is a component we created in Angular to wrap React components, allowing them to be used as if they were native Angular components. This hybrid approach allowed both frameworks to exist at the same time, enabling an incremental transition from the old framework to the new one within the existing codebase. Using this tool allowed us to continue rewriting old components and building new ones directly in the React component library. As a result, new features were built in React, reducing the need for rewrites and helping developers gradually get up to speed with React through hands-on feature development. + +++The old library was difficult to maintain, as every change introduced bugs or made it hard to extend some of the components. Working with the Crocoder team, we were able to rethink the architecture, implement new core components quickly, and start using them alongside the existing ones. Development became faster and more consistent, especially with the new Storybook documentation, which made the library much easier for the team to adopt and extend. Throughout the process, they shared their knowledge with our teams to enable us to confidently maintain and evolve the library on our own.
++ — Andreja Migles, Senior Software Engineer at Conductor (formerly Searchmetrics) +
+
++ +### Making the Shift Easier for Developers + +Aside from the technical changes that had to be made, we needed to focus on mentoring the developers to learn React, and quickly. To get an idea of the developers’ knowledge of React, we created a poll where they assessed how familiar they are with the framework. The results showed that not a lot of developers had any experience with React, meaning we needed to start with the basics and gradually work our way to more complex aspects. The maintenance and updates of the app made this more challenging, as it left the developers with limited time to focus on learning. This is where our approach of identifying motivated developers came into play: those eager to learn were mentored first, which enabled them to support their teammates with React-related tasks and help spread the knowledge across the organization. + +💡 By enabling AngularJS and React to coexist within the same product runtime, our approach made it possible to transition incrementally. It allowed us to rewrite legacy components while building new ones directly in the React component library, all without disrupting ongoing development and without doing double the work.
+
++ +### React Workshops + +We organized a range of workshops, from React 101 to more advanced topics, repeating each session to accommodate different schedules and ensure everyone could attend. These sessions provided a theoretical foundation through presentations and code examples, while also helping us identify developers eager to learn and support the migration. Their motivation was key to successful knowledge transfer; without their engagement, the project risked becoming difficult to maintain after our involvement ended. + +### Knowledge Sharing Through Group Sessions + +At sevdesk, a company-wide decision allowed developers to take one day each month away from product work to focus on projects of their own choosing. We adopted this concept and proposed organizing group coding sessions on that day. Unlike the more theoretical workshops, these interactive sessions focused on coding in React. We covered the basics such as creating simple pages, building components, managing state, navigating between pages, etc. + +Other developers would follow along, try coding something on their own, and ask questions whenever something was unclear. To ensure that every part of the code was properly migrated and maintainable in the future, we made sure to invite a few developers from each team to participate. + +While off-product work can sometimes feel fragmented or disconnected, these group sessions were focused and intentional, contributing to long-term improvements in the product. + +### Pair programming + +Pair programming turned out to be a highly effective method for hands-on coding support in this project. Initially, developers were hesitant to ask for help, so we took the initiative by offering guidance on new features and React. After a few programming sessions, developers started reaching out on their own, asking for support and assistance with adding new components. + +## The Turning Point + +When it comes to large initiatives and changes, it may take some time to see the fruits of your labor, but that doesn’t mean you are on the wrong track. Our efforts proved effective when two developers from the same team reached out to us requesting new components. Unlike before, when such tasks were assigned to the Core team, they now wanted to build the components themselves with our support. This was a huge step forward, as it showcased the willingness and motivation of the developers to start coding in React and participate in the migration. After a few pair-programming sessions, the first components not created by the Core team were added to the new component library. Because of this, the two developers continued working on maintaining these components independently. + +Following this, an increasing number of developers from different teams started reaching out to us, eager to try coding in React with our support. In some cases, the learning process was faster, in others slower, but the end result was the same: they successfully contributed to the migration. This led to more teams having developers capable of maintaining the new React code without relying solely on the Core team. + +As the number of developers who grasped the basics of React increased, the task of educating the rest of the developers also shifted from the Core team. This reassured us that we were on the right path to finalize the migration, and that the developers will be able to maintain and improve the code on their own. + +## Key Takeaways + +When migrating from one framework to another, there’s no one-size-fits-all solution. Each project has its own unique challenges shaped by the development team, existing architecture, and long-term goals. + +Key elements of a successful migration include: + +- Creating a strategy tailored to your specific needs that aligns with both your team and product +- Remaining flexible throughout the process and being prepared for unexpected issues or changes +- Prioritizing a smooth experience by focusing on both developer workflows and end-user satisfaction + +By getting to know the client, the development team, and the product, we were able to plan out the migration strategy that worked for sevdesk. We helped them to carry out a smooth migration with zero downtime, no feature freezes, all while maintaining a high-quality developer and user experience. During our collaboration, we emphasized that technical excellence must go hand in hand with organizational changes and adaptations—without this alignment, improvements tend to be short-lived. Alongside the migration, we shared our knowledge of React and best practices with the development team, equipping them with the tools needed to maintain and upgrade the product well into the future. + +If the things we’ve discussed hit close to home, [contact us](https://www.crocoder.dev/#book-a-call-section)—we’d be happy to help you plan your migration. diff --git a/apps/website/src/content/posts/no-deployments-on-friday-sucks.md b/apps/website/src/content/posts/no-deployments-on-friday-sucks.md index b7b79dfd..7470f816 100644 --- a/apps/website/src/content/posts/no-deployments-on-friday-sucks.md +++ b/apps/website/src/content/posts/no-deployments-on-friday-sucks.md @@ -1,6 +1,6 @@ --- title: "\"No Deployments on Friday\" sucks" -description: "Explore the debate on 'no deployments on Fridays' in tech — a sign of caution or a red flag? Unpack the truth behind this rule's impact on engineering culture, team confidence, and system reliability." +description: "Explore the debate on 'no deployments on Fridays' in tech—a sign of caution or a red flag? Unpack the truth behind this rule's impact on engineering culture, team confidence, and system reliability." createdAt: 1699736934343 updatedAt: 1699736934343 authors: ["david"] @@ -11,7 +11,7 @@ image: "/images/no-deployments-on-friday-sucks.png" draft: false --- -The common industry maxim of "no deployments on Fridays" often carries a certain prestige — seen as a hallmark of a mature, responsible engineering culture. +The common industry maxim of "no deployments on Fridays" often carries a certain prestige—seen as a hallmark of a mature, responsible engineering culture. For many, it's a rule to avoid potential headaches when everyone wants to start their weekend. It might sound smart, but it could also be a red flag that something's not quite right with the team's confidence or their tools. diff --git a/apps/website/src/content/posts/turning-metrics-into-direction-for-your-team.md b/apps/website/src/content/posts/turning-metrics-into-direction-for-your-team.md index 4cd316e6..c573d665 100644 --- a/apps/website/src/content/posts/turning-metrics-into-direction-for-your-team.md +++ b/apps/website/src/content/posts/turning-metrics-into-direction-for-your-team.md @@ -52,7 +52,7 @@ While this approach keeps things simple, you’ll still want to steer clear of c A friend told me about a company they worked for that set a secret target of "X pull request (PR) per week" per engineer. As soon as this was found out, PR count skyrocketed, yet output quality plummeted. People took normal-sized PRs and split them into tiny PRs just to meet the quota. The metric was reached, but the actual velocity of meaningful work tanked. -This is the classic pitfall of using a lagging indicator, an end-result metric that doesn’t tie back to the cause. I covered this in more detail in my post ["No, you shouldn't measure developer productivity.."](https://www.crocoder.dev/blog/you-should-not-measure-developer-productivity-response-to-mckinsey). +This is the classic pitfall of using a lagging indicator, an end-result metric that doesn’t tie back to the cause. I covered this in more detail in my post ["No, you shouldn't measure developer productivity..."](https://www.crocoder.dev/blog/you-should-not-measure-developer-productivity-response-to-mckinsey). When you push on a lagging indicator, folks often find creative ways to "hit the target" without changing the underlying problems. diff --git a/apps/website/src/content/posts/using-lago-to-create-a-flexible-billing-system.md b/apps/website/src/content/posts/using-lago-to-create-a-flexible-billing-system.md index 38132e55..d0d4505e 100644 --- a/apps/website/src/content/posts/using-lago-to-create-a-flexible-billing-system.md +++ b/apps/website/src/content/posts/using-lago-to-create-a-flexible-billing-system.md @@ -4,10 +4,10 @@ description: "Billing systems shouldn’t break when your business changes. Star createdAt: 1753226376766 updatedAt: 1753226376766 authors: ["stefan"] -category: "SOFTWARE ARCHITECTURE" +category: "CASE STUDY" editors: ["velimir"] abstract: "Startups thrive on agility, but their billing systems often don’t. While product roadmaps and pricing models shift rapidly in pursuit of growth and product–market fit, billing infrastructure tends to lag behind, creating friction just when flexibility is needed most. In this post, we unpack how we helped Submix, a real-time audio collaboration platform, build a future-proof billing foundation tailored to constant change. By leveraging Lago, an open-source, usage-based billing engine, we delivered a system designed for adaptability, not rigidity. The result: seamless transitions between pricing models, faster go-to-market iterations, and full ownership over billing logic and data. For fast-moving teams, treating billing as a strategic lever, not an afterthought, can unlock speed, resilience, and long-term optionality." -image: "/images/using-lago-to-create-a-flexible-billing-system.png" +image: "/images/using-lago-to-create-a-flexible-billing-system-2.png" draft: false --- @@ -35,7 +35,7 @@ Initially, Submix used a **simple pay-per-call model**. Users could purchase ind This simple model suited their **B2C strategy** well, as predictability and ease of use were critical for attracting early adopters. But as the product evolved, and new features launched, it became clear that a more dynamic billing approach would be required to support their growth. -💡 By identifying developers who showed strong motivation to learn and mentoring them first, we empowered them to become catalysts for spreading React knowledge throughout their teams and the organization.
+
+@@ -45,7 +45,7 @@ To accommodate these shifts, they introduced a **fixed-price subscription model* The pricing model continued to evolve; first with **overage charges** layered onto the subscriptions, and later transitioning to a **fully usage-based, pay-as-you-go** system for individual users that offers maximum flexibility. **Free trial periods** were also introduced to lower the barrier for new users and encourage onboarding. -💡 Before a startup finds a market fit, pricing models will inevitably shift. Recognizing this, the Submix team supported our vision for a billing foundation designed for adaptability from day one, understanding that it's what separates momentum from setbacks.
+@@ -55,6 +55,15 @@ When Submix needed to introduce a subscription billing model, their marketplace That limitation, combined with our expectation of future pricing complexity, led us to explore dedicated billing platforms that could integrate with our stack and grow with the business. +💡 Choosing the right billing foundation early on allowed us to pivot from fixed pricing to flat-fee subscriptions, and later on to hybrid and usage-based models. All this in just days, without major rework. Our future selves were grateful.
++ ### Our Evaluation Priorities We approached the decision around selecting a billing platform with a long-term architectural perspective in mind. Key priorities shaped our evaluation process: @@ -70,7 +79,7 @@ Lago stood out for its open-source foundation, deployment flexibility, and nativ It gave us the technical control we needed without introducing complexity, and served as a solid foundation that could support experimentation, growth, and long-term maintainability. -++CroCoder have been a great partner during the growth of Submix, and the development of our billing system is a great example of their approach to working with us. They're proactive, anticipate our needs, and bring a wealth of knowledge and experience. We trusted their recommendation to use Lago for our billing system, which turned out to be the right call for a future-proof system.
++ — Douglas Barr, Co-Founder and CTO at Submix +
++@@ -86,7 +95,7 @@ During live call sessions, user activity, such as entering or leaving a call, is Users can track their usage data directly within the app. This data is pulled from our processed billing records, providing clear, up-to-date feedback aligned with their subscription status. -💡 Choosing Lago gave us the freedom to build around the business, rather than forcing the business to conform to the tool.
+@@ -98,7 +107,6 @@ By designing Submix’s billing solution around Lago, and integrating it with th Because of the architectural flexibility, Submix was able to shift from per-session purchases to fixed monthly subscriptions, and later to overage-based and fully usage-based models, all within days. When usage-based billing was introduced, no major rework was needed thanks to the broad capabilities of Lago in conjunction with our established usage tracking. Adding overage logic and reconfiguring pricing rules was fast and non-disruptive. These rapid rollouts were a direct result of designing for change from day one. - ### Highly Flexible Billing Adjustments Pricing rules can be fine-tuned with ease, from trial durations, to usage thresholds, to **custom subscription terms for individual customers**. @@ -111,7 +119,7 @@ Lago offers both robust cloud and self-hosted options. We deployed and managed t Developers can simulate billing flows locally, test quickly, and release with confidence. -💡 Our approach at Crocoder prioritizes future-proof and adjustable solutions. This was clearly demonstrated in the system that we built for Submix, which allows them to evolve their pricing models or billing processes without major rework.
+@@ -123,4 +131,4 @@ By building a system around Lago and carefully integrating it with the rest of t More importantly, this project highlights a key lesson for any evolving product: investing in **future-ready billing architecture** early on can unlock faster iteration, smoother pivots, and lower long-term costs. Startups often go through major shifts while finding product–market fit. It’s a pattern we’ve come to expect and design for. -For teams navigating evolving pricing models, experimenting with usage-based billing, or looking to avoid vendor lock-in, a flexible billing foundation isn’t just a technical choice, it’s a strategic advantage. \ No newline at end of file +For teams navigating evolving pricing models, experimenting with usage-based billing, or looking to avoid vendor lock-in, a flexible billing foundation isn’t just a technical choice, it’s a strategic advantage. diff --git a/apps/website/src/content/posts/you-should-not-measure-developer-productivity-response-to-mckinsey.md b/apps/website/src/content/posts/you-should-not-measure-developer-productivity-response-to-mckinsey.md index c610efa8..8ab90474 100644 --- a/apps/website/src/content/posts/you-should-not-measure-developer-productivity-response-to-mckinsey.md +++ b/apps/website/src/content/posts/you-should-not-measure-developer-productivity-response-to-mckinsey.md @@ -1,5 +1,5 @@ --- -title: "No, you shouldn't measure developer productivity.." +title: "No, you shouldn't measure developer productivity..." description: "Explore the contentious debate surrounding developer productivity measurement ignited by McKinsey's recent article. Discover why focusing on individual metrics hinders software engineering teams." createdAt: 1695115503000 updatedAt: 1695115503000 diff --git a/apps/website/src/content/services/lead-migrations-without-imacting-customers.md b/apps/website/src/content/services/lead-migrations-without-imacting-customers.md index 2221693c..510a0834 100644 --- a/apps/website/src/content/services/lead-migrations-without-imacting-customers.md +++ b/apps/website/src/content/services/lead-migrations-without-imacting-customers.md @@ -9,3 +9,11 @@ bgColor: "bg-[#5362DBE5]/[0.9]" --- Move away from legacy systems and navigate major tech initiatives such as new framework adoptions, without disrupting your users. Whether you need end-to-end delivery or staff augmentation, our bottom-up approach empowers your existing teams to drive change sustainably and confidently. + + + + +Case Study: Rebuilding Legacy UI + diff --git a/apps/website/src/content/services/upskill-existing-team.md b/apps/website/src/content/services/upskill-existing-team.md index 1095af61..bf8ca293 100644 --- a/apps/website/src/content/services/upskill-existing-team.md +++ b/apps/website/src/content/services/upskill-existing-team.md @@ -9,3 +9,11 @@ bgColor: "bg-[#1E1A1AE5]/[0.9]" --- Help your team keep up with industry demands through dedicated mentorship and hands-on support. We offer technical coaching, on-the-job pairing, and structured growth plans to identify and close skill gaps so your developers become more effective and confident with modern technologies and practices. + + + + +Case Study: Sevdesk's Road to React + diff --git a/apps/website/src/content/testimonials/1raphael-bauer.md b/apps/website/src/content/testimonials/1raphael-bauer.md index 1eeff664..ce00f1bf 100644 --- a/apps/website/src/content/testimonials/1raphael-bauer.md +++ b/apps/website/src/content/testimonials/1raphael-bauer.md @@ -4,5 +4,5 @@ name: "Raphael Bauer" title: "CTO" company: "Interim" --- -CroCoder is one of the **most trusted partners** in my network. We have successfully completed multiple projects in the past. I highly recommend CroCoder - **their team is exceptional** and they will offer you outstanding support for your projects. I look forward to future collaborations with CroCoder! +CroCoder is one of the **most trusted partners** in my network. We have successfully completed multiple projects in the past. I highly recommend CroCoder — **their team is exceptional** and they will offer you outstanding support for your projects. I look forward to future collaborations with CroCoder! diff --git a/apps/website/src/content/testimonials/2paul-jeszensky.md b/apps/website/src/content/testimonials/2paul-jeszensky.md index d25e38ea..08caf3d6 100644 --- a/apps/website/src/content/testimonials/2paul-jeszensky.md +++ b/apps/website/src/content/testimonials/2paul-jeszensky.md @@ -4,5 +4,5 @@ name: "Paul Jeszenszky" title: "co-founder & CEO" company: "Submix" --- -We have found **the perfect extension of our team** with CroCoder. We operate as one team, celebrating our wins and working through the challenges together. They “own” the roadmap, deadlines and outcomes with us - from the ideation and direction stages through to post-launch optimization. +We have found **the perfect extension of our team** with CroCoder. We operate as one team, celebrating our wins and working through the challenges together. They “own” the roadmap, deadlines and outcomes with us — from the ideation and direction stages through to post-launch optimization. diff --git a/apps/website/src/content/testimonials/3michele.md b/apps/website/src/content/testimonials/3michele.md index cb517093..675d33ea 100644 --- a/apps/website/src/content/testimonials/3michele.md +++ b/apps/website/src/content/testimonials/3michele.md @@ -4,4 +4,4 @@ name: "Michele Rattotti" title: "Project Manager" company: "4evergreen" --- -We were impressed by the proactive attitude [of CroCoder] and capacity to **turn theory into practice**. Their support and assistance was very timely and precise, always followed by concrete implementing steps. The small team has a **strong multidisciplinary background** and proved **a good attitude** to work in team with other consultants +We were impressed by the proactive attitude [of CroCoder] and capacity to **turn theory into practice**. Their support and assistance was very timely and precise, always followed by concrete implementing steps. The small team has a **strong multidisciplinary background** and proved **a good attitude** to work in team with other consultants. diff --git a/apps/website/src/content/values/aligment-business-goals.md b/apps/website/src/content/values/aligment-business-goals.md index 135296c6..dbaa5736 100644 --- a/apps/website/src/content/values/aligment-business-goals.md +++ b/apps/website/src/content/values/aligment-business-goals.md @@ -6,4 +6,4 @@ icon: "/target-black.svg" --- We don’t just build software, we build solutions that drive real impact. Every feature we create serves a purpose, aligning seamlessly with your business strategy. -No fluff, no waste—just results. +No fluff, no waste — just results. diff --git a/apps/website/src/pages/staff-augmentation.astro b/apps/website/src/pages/staff-augmentation.astro index c1bff069..376589a5 100644 --- a/apps/website/src/pages/staff-augmentation.astro +++ b/apps/website/src/pages/staff-augmentation.astro @@ -154,7 +154,7 @@ const { ogImage = "https://www.crocoder.dev/homepage-metadata-img.png" } =💡 While business change is a constant reality for startups, experience has taught us precisely why architectural flexibility yields the highest returns.
- We have found the perfect extension of our team with CroCoder. We operate as one team, celebrating our wins and working through the challenges together. They "own" the roadmap, deadlines and outcomes with us - from the ideation and direction stages through to post-launch optimization. + We have found the perfect extension of our team with CroCoder. We operate as one team, celebrating our wins and working through the challenges together. They "own" the roadmap, deadlines and outcomes with us — from the ideation and direction stages through to post-launch optimization.
@@ -281,7 +281,7 @@ const { ogImage = "https://www.crocoder.dev/homepage-metadata-img.png" } =- We Specialise in Building
Web Products + We Specialize in Building
Web ProductsOur engineers work with modern stacks like React, TypeScript, Node.js, Next.js, GraphQL, and more — but we're not dogmatic. We choose the right tools for the job.