small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

**We all feel that the whole world is spinning faster and faster, not only in terms of technology but also in the way we do business. Here are some bits of predictions on what is likely going to happen in the next few months, brought to you by our CEO, CTO, and CRO.**

### **Adrian Roth** - CEO
> *I am somewhere in between a humanist and a scientific mind. Although I am a philosopher by education, my experience includes management, communication and broadly understood technological issues.*


#### **1. Bringing up the new generation of developers**
If we look at hiring rates and an interest for new developers in Poland and around the world, we can see a gap - depending on who estimates - of 50 thousand up to even 300 thousand programmers in market demand. So we face an industry need on the one hand and a lack of new programmers on the other. Something has to be done, and in the long run a constant race between businesses for new employees that are being taken out from competing companies is not benefiting anyone. 

It leads to high uncertainty in project management, a bigger risk of client churn, and is not good for the IT industry in the long run.

What we can do, aside from looking at closer cooperation with universities and schools, is to start to teach and to create a space for new developers' promotion inside the companies. It is costly and demands a long-term strategy, but this is a price we need to pay to be able to develop and grow our businesses. 

#### **2. New budget ranges and the problem of the pile of money**
Last year, markets were flooded with a huge amount of money and tech businesses got used to ever-larger budgets for digitization (e.g. for IT services and product building). This year we can already see the first signs of the crisis and it surely will make investors less willing to spend money and is going to drive them to make more informed decisions. If we put it together with - sometimes missed - expectations of IT service providers, it may lead to problems for some organizations that are not prepared for shifting from last year’s boom into an upcoming downfall.

#### **3. Instability in Ukraine - as a potential threat for the region**
If a large-scale military conflict in Ukraine (and Belarus) begins, it is possible that companies running IT projects in this region will turn their eyes to other markets, including Poland. If we consider all three topics mentioned, the situation in 2022 can be both a threat or more likely a chance for the Polish tech industry. Of course, a lot depends on whether the money will be spent wisely, and if tech companies are ready to create an environment in which there will be a space for the education of more specialists.

### **Łukasz Roth, CTO**
> *For me, being a CTO means trusting and delegating technology decision-making to the teams.*


#### **4. Efficient remote engineering teams management**
The year 2022 will be a time where remote work of engineers will not be an exception, but a new standard in our industry. What is already routine for members of technical teams, will continue to be a challenge for project managers. Transformation of processes and methods of communication is inevitable, and the market advantage will be achieved by companies that will adapt faster to the new reality and be able to deliver business value to their customers with the same efficiency and the same high quality as before changes.

#### **5. Enterprise jamstack & nocode solutions**
The digital transformation is speeding up, not from year to year, but monthly. Increasing market expectations put pressure on technical teams to deliver solutions at a faster pace. The approach in which the programmer assigns as much responsibility as possible to external services and focuses his work on architecture and business logic fits perfectly into this trend. Headless CMS, headless e-commerce, (Amazon / Google / Azure) Cloud in projects is no longer a surprise. We buy more and more services such as data, identity, and operations in the PaaS model, and we focus on the value unique to the client's needs and ideas. Projects can be validated on the market much faster, and we can witness more specialization in developers' work.

#### **6. Knowledge sharing, soft skills development** 
Any forward-thinking and responsible organization must start investing its time and resources in knowledge transfer. The demand for software engineers in the market is very high, the expectations of professionalism are as high as never before. Nothing happens in a vacuum, if we want to give more responsibility for the tech industry to qualified people, we have to start preparing them now. Market demand lowers standards. If we do not want to let that happen as an industry, this is the time to act. Moreover, the days when a programmer was responsible for code and only code ended a few years ago. Currently, a mature engineer is required to have a whole range of soft skills, and it is also worth taking care of strengthening these qualities in your teams.

### **Greg Motriuk, CRO**
> *I build stable, long-term software development teams in Poland for clients worldwide.*


#### **7. Technological elasticity**
For the next few years, we will witness an increase in the flexibility of experienced engineers in the domain of shifting between technologies. It is true that we live in a world of specialization, but the pace of development of new technologies is so fast that moving from PHP to Node.js should be a new must-have skill-set for every experienced developer. 

Of course, specialization has its advantages, but if you are a mature developer, your background and knowledge is more important, and you should be able to become a senior in new technology within months if you put in enough effort. 

In companies and projects, this kind of skill-set is going to be in bigger demand, so don't be afraid to do that, especially when it is not necessary to always fit in 100%. If you are experienced and flexible, you can start the journey now, and get better with time passing.

#### **8. Ultrafast decision making - startupization of tech industry**
It used to take months to finish an initial part of a deal on software development, and today - in many cases - it takes only a few days. In the blink of an eye, your potential development team can sail to another project - that is how much good coding skills are in demand on the market. And companies (clients) started to realize that. 

The entire industry is going through a "startupization" phase, and it is very important to have a partner who combines business and tech maturity with the speed and flexibility of a startup. In the past, if you got something immediately, it wasn't of good quality. 

Now you have to be precise and fast. Luckily the whole tech industry got more mature and experienced, so it is easier to find a good fit for new challenging projects. 



large_Blog_artykul_Adrian_Lukasz_Grzegorz_prediction_cover_high.png

medium_Blog_artykul_Adrian_Lukasz_Grzegorz_prediction_cover_high.png

small_Blog_artykul_Adrian_Lukasz_Grzegorz_prediction_cover_high.png

thumbnail_Blog_artykul_Adrian_Lukasz_Grzegorz_prediction_cover_high.png

Blog_artykul_Adrian_Lukasz_Grzegorz_prediction_cover_high.png

A Bit of noise in the predictions about the tech scene at the beginning of 2022

Frontend Engineering

UX/UI Design

Research & Discovery

AI For Your Business

Services

Case Studies

About us

Blog

React has been around for a while, and it is currently the leading frontend framework (ok, library). It somehow manages to stay ahead of the pack despite tough competition. The React community is massive and that in itself is a good enough reason to expect a framework to stay popular as the adoption curve cycle slowly plays out. This sort of drift, however, is definitely not what’s happening with React. In fact, React stays popular because it keeps reinventing itself in the attempt to answer the changing needs of UI engineering (and, for the most part, does so gracefully, without compromising backwards compatibility).

This article looks at React's latest attempt to chart a new course, this time by laying out a bold vision around extending the component ecosystem into the server with **React Server Components**. The technology is not yet fully production ready, but you can already test early implementations offered by Next.js (and Remix might soon follow suit), and so it is probably mature enough that decision makers in companies using React (or considering using React) should start paying attention. 

First let’s understand the challenges the React team is trying to address and then look at potential adoption challenges and how the way we build and structure teams of React developers going forwards would change should the vision be brought to fruition.


#### **Why is React evolving towards the server side?**
It may come as a surprise if you’ve worked with react for years, but the React team now recommends to start new React projects through fullstack React metaframeworks:

![ ](\uploads\blog-serverReact_post_01_7EIWdEC0ow4M5qFf65l5pA.png)
*Source: react.dev*

The emphasis on using a framework is such that they felt it necessary to preempt the question of whether React is still its own thing.

![ ](\uploads\blog-serverReact_post_02_6XqaSpCjS2vNDLNmmc5Vy2.png)
*Source: react.dev*

This is quite a shift, considering that for the longest time the recommended solution was to use CreateReactApp - a tool built by the react team which spins up a React SPA (i.e. a client side only app). **What explains that change?** In short, React Server Components. Answering this question in a bit more detail is still rather challenging though, because – while the authors know the answer very well – they’re still figuring out the best way to communicate this to the outside world in a way that would capture people’s imagination. Luckily, **Dan Abramov from the React core team has lately given us a sneak peak** of their thinking by testing some pitch ideas for React Server Components on his private twitter account.

![ ](\uploads\blog-serverReact_post_03_7Ct4KhNuhk4eZXZDX0I28K.png)
*Source: Twitter*

You can read the whole thread here:

["i need to start collecting ways to pitch react server components.](https://twitter.com/dan_abramov/status/1631885118355718144?lang=en-GB)
"

But here’s my top 3.

#### **Best pitch for Server Side Components: 3rd place**
![ ](\uploads\blog-serverReact_post_04_jsP1HQs3YXsp6dBnnm21l.png)
*Source: Twitter*

This one, Dan readily agrees, is a little hyperbolic - but then most good sales pitches are. It gets third place because it’s rather inaccurate, but it does communicate the promise of having to think about getting data as part of architecting your UI much less often. 

Currently the data fetching pattern the react team has converged on is all about favoring collocation of components and data fetching, i.e. each component knows what data it needs and fetches it as required. There are many benefits of this approach, full composability being probably the largest. The drawback is that, since all that fetching happens on the client, each component triggers its fetching logic only once it gets rendered, which depends on the ancestors having been rendered and having fetched their data etc. - a waterfall of queries ensues, and the need to cache and dedupe requests on the client presents itself very quickly as the app grows. 

In Meta (React’s mother company) that is handled by the Relay framework, which facilitates stitching together a top level GraphQL query based on data dependencies declared locally by every component. It then takes care of optimizing a single top level query, which includes deduplication (the same data requested by multiple components gets requested once). Relay is a very powerful solution, check out this talk by Robert Balicki from the React Data Team to learn more: [https://www.youtube.com/watch?v=lhVGdErZuN4](https://www.youtube.com/watch?v=lhVGdErZuN4)


While RSC and Relay are very different things and might be used in conjunction, **they do have an overlap when it comes to solving request orchestration and deduplication**, i.e. in both cases developers worry less about optimizing data fetching. 

Here’s another tweet from Dan, which sadly didn’t make it to the top three: “**read data on the server, pass it down by props**”. This means developers would essentially be able to “think in components” also on the server. With React Server Component you can simply await a promise inside a (server) react component instead of fetching from the browser. 

The best part is that you’re not limited to treating your server components as “all knowing parents” responsible for getting all the data children need (which is what route level fetching in Multiple Page Applications is). Instead, you can be as granular as you want. You might choose to place a server component at the bottom of the React tree even if it has client rendered ancestors. Hopefully this illustrates why React developers in the future might worry less about using APIs and instead focus on the best ways to combine components, each of which would handle their own fetching concerns, with the actual fetching benefiting from some optimizations higher up.


#### **Best pitch for Server Side Components: 2st place**
![ ](\uploads\blog-serverReact_post_05_6oyCT94PSinGhUFajfUJ25.png)
*Source: Twitter*

This one is the key to understanding why building server first React components sits well specifically with React. The concept of facilitating the component based UI architecture paradigm both on the frontend and the backend is not limited to React but React’s unidirectional data flow is especially well suited to play well with such a setup. 

React treats the UI primitives like they are just values. You can keep them in variables, pass them around and compose them into larger groupings that behave predictably precisely because data flows through them only one way.

![ ](\uploads\blog-serverReact_post_06_4DCvJN1QEpawIimpDTpJpr.png)
*Source: Twitter*

Subsections of the component tree get selectively rerendered as required in order to reflect changes in data. It is therefore important to control at which level of the virtual dom tree the data changes are detected and reacted to. React developers know this problem as “lifting state up”, i.e. moving a piece of data as high up as necessary (closest common ancestor), but not higher (to avoid unnecessary rerenders). 

Now thanks to React Server Components developers can design their state architecture the same way but they can now decouple the problem of component structure from the challenges of sourcing the data in a streamlined fashion. 

With RSC, what arrives in the browser is a serialized json describing the react tree with the server side components already broken down into base html tags containing the results of any data crunching that happened on the server (it also contains elements acting as placeholders for client side rendering). There is no rerender triggered by the fetched data suddenly arriving somewhere higher up in the tree. In this sense, the server data orchestration serves as the top level of the unidirectional data flow, even if the components themselves are deeply nested in the react tree structure and have client rendered ancestors. Powerful stuff.

#### **Best pitch for Server Side Components: 1st place**
![ ](\uploads\blog-serverReact_post_07_5rVtbB7A2yPrv3agQ2Dp2r.png)
*Source: Twitter*

This pitch idea hits the nail on the head, I think. It’s all about still thinking in components but extending the composability. SRC is an entry point to the future where react components can be published on NPM and have their own data fetching concerns fully met out of the box rather than having to rely on app developers to understand what data is needed. 

This is the benefit that is much more interesting to CEOs than the details of how this is actually achieved. Imagine how much more streamlined the work of large react teams becomes if components can handle their own data in a way that allows you to put them together in more complex groups without footgunning yourself. 

That vision is definitely appealing. So, what are the drawbacks and challenges we might expect should it be realized?

#### **Fullstack React: added complexity vs metaframework lock-in**
The already mentioned emergence of react meta-frameworks, i.e. frameworks built on top of React, is not a problem in itself - on the contrary - next.js, remix and other frameworks have a lot to contribute. 

That said, React team deferring to these frameworks as a way to start an application tells you something about the fact that delivering on the vision outlined above no longer sits solely within the remit of React. The bits frameworks care about now become an integral part of delivering your UI to your users. What follows is that you might have to acknowledge that choosing React as your UI technology will now have potentially further reaching consequences and may come with added complexity. In other words, choosing React is no longer just choosing one of many flavors of V in MVC. 

This sounds like a lot of additional headache, doesn’t it? It doesn’t have to be! The whole point of the shift towards starting with a slightly more complex setup than just a SPA means that **you’re not locking yourself into a SPA** - and that’s a huge benefit as it saves you some serious grief in the future. Adding all the server-y bits to a bloated SPA is a complex endeavor. To avoid it, you may want to start with running RSC at build time (so react server components but – sort of – without a server) and then shift towards using whatever mode makes sense on route by route basis (and yes, there is a Dan Abramov tweet to back this up too). 

Does it mean that you should marry a metaframework? Maybe, and maybe not - either way, it’s now up to you to understand what such a framework does for you, and the answer is no longer simply based on whether you need SEO and hence need SSR. By the way, RSC is not the same as SSR. Server side rendering can be set up to play nicely with React Server Components though, and that’s partially also what metaframeworks do for you. 

One thing to consider is that server rendering runtimes are now a thing. As your UI app no longer lives solely in the browser, hosting becomes potentially more complex than just dropping a SPA bundle on a CDN. UI architecture considerations would now need to extend to deciding what your SRC server rendering environment requirements are. For example, Next.js now offers three different server rendering runtimes (node, node serverless, edge) - each with its own characteristics when it comes to security, latency, scalability and IO access and each with its own tradeoffs (e.g. code ran on the edge cannot exceed a certain size etc.). If you don’t want to be married to Vercel (the hosting company behind Next.js) - you need to roll your own. If you don’t mind tying yourself to a hosting provider, that has consequences too. 

Another thing to consider is that with SRC bundlers play an increasingly important role. Your bundler would now be tasked with generating serializable “module reference” objects, i.e. creating the server side placeholders for client rendered components, and then helping the client stitch the tree back together following the client rendering step. If you bootstrapped your project with a metaframework, this won’t be an issue. If you’ve got your own bundler setup, it might be something to look into. 

Yet another consideration is caching your rendered components (see static vs dynamic rendering in Next.js for an example of that). You might also be curious if your “backend for frontend” can rely on other technologies than javascript (not yet as far as I know, but that may soon change) and so on – there are potentially many more such technical challenges, which fall outside of the scope of this article. We’ll surely discover even more once the technology is mature enough to be production ready. 

What is obvious already, however, is that all of the above potentially impact the way you should source technical talent for react teams. Let’s look at why that is.



#### **What fullstack react means for sourcing React talent**
If the react community does embrace the metaframework first approach, one immediate consequence is that React skills will become less transferable. Familiarity with React via Next is not necessarily going to equate to familiarity with React via Remix - not to mention that we can expect to see meta-metaframeworks, i.e. more domain specific frameworks to be built on top of metaframeworks (e.g. Shopify hydrogen 2.0 is built on top of Remix). Each metaframework offers different abstractions and each is going to be incentivized to differentiate its offering. Competition is always great for end users, but bear in mind skill transferability may suffer. In your hiring you may therefore be well advised to pay more attention to the understanding of the underlying server related concepts, not framework trivia. 

Another consequence is that - metaframework or not - the mental model of react stretched across the network boundary becomes increasingly complex when it comes to debugging, optimization etc. Also, marrying the current client-heavy toolset with SRC may prove challenging. For starters, here is Jack Harrington building a toy Next.js 13 app using redux toolkit both on the client and the server and initializing the client store with values from the server store:

State Management for NextJS 13 Server and Client Components by Jack Herrington

This is to say that spreading React both on the client and the server may yield new challenges which you may want to test for or upskill towards. 

At this stage you may ask: is it worth all the hussle of revamping your HR practices just because one framework came up with a new feature? My answer in this particular case would be yes, if you believe this trend is wider than RSC - and I believe it is. 

Consider for example, that the same trend has been playing out in the C sharp world. .Net developers discovered the benefits of component based composability by going from MVC and razor pages to the Blazor framework, which came in two flavors. Blazor server, offering server rendered UI components, and Blazor Web Assembly, which works pretty much like every other SPA framework but relies on .net instead of javascript, crammed into the browser courtesy of webassembly. 

Now with .net eight on the horizon there is a new flavor of Blazor in town, called Blazor United, which promises to give developers the best of both worlds by allowing them to define which components should render on the server and which should be treated as client components. Sounds familiar? Here’s Jon Hilton explaining the details of how Blazor United came to be, and comparing it to Remix: [https://jonhilton.net/blazor-united/https://jonhilton.net/blazor-united/](https://jonhilton.net/blazor-united/)


This is not to say that server heavy UI frameworks are somehow a historical inevitability. The split between frontend and backend development is a valid one - at least for larger organizations. However, what seems to be more and more evident is that this split doesn’t align with the split between the server and the browser as neatly as we once thought. Instead the fault line seems to be between UI related concerns (spanning both server and frontend) and non UI related concerns. The talent sourcing consequences are pretty obvious if you look at it this way, and they go well beyond React. 

#### **Summary**
It’s still early days for RSC but it seems like it’s time to start looking at the details of what server-first React means for our organisations. 

#### **About the author**
[Jan Bełezina](https://www.linkedin.com/in/jan-belezina-7356055a/)
 is a software engineer and guest blogger for Bitnoise, based in Oxford. He specializes in React, Three.js, Next.js, and TypeScript. As a former product manager and business analyst, he has a wide overview of the development process and strategies.

large_blog-serverReact_cover_high.png

medium_blog-serverReact_cover_high.png

small_blog-serverReact_cover_high.png

thumbnail_blog-serverReact_cover_high.png

blog-serverReact_cover_high.png

The server-first future of React – guide for CTOs

In this blog post, I will explore the responsibilities and significance of a Chief Technology Officer (CTO) role in startups and scaleups and the factors that should be taken into account when deciding between employing an in-house CTO or opting for the services of an external consultant ([CTO as a Service](https://www.bitnoise.pl/services/cto-as-a-service)
). 

**Let's begin with a fundamental question: What is the role of a CTO and what does their operational environment encompass?**

My focus will center on two primary contexts: startups during their initial financing and development phase, and established organizations during the scaling phase. While I acknowledge the existence of other possibilities, the purpose of this post is to offer insights rather than provide an exhaustive list of technological roles. Furthermore, I assume that the distinction between CTOs and Tech-Leads is less significant at this stage, as these roles often interchange and the nomenclature arises more from chance than deliberate decision-making.

#### **The most important qualities of a good CTO**
A Chief Technology Officer (CTO) is a highly skilled professional who assumes overall responsibility for the technological aspects of your startup. They bring extensive experience and expertise in understanding the inner workings of your solution and delivering value to end-users. However, it is essential to consider additional dimensions of this role.

**CTOs come from diverse backgrounds, often having held positions as software developers, tech leads, DevOps specialists, project managers, or even academic personnel.** Within your startup, their responsibilities may encompass technological leadership, research and innovation, business and technology development, product development, and the recruitment of key technical specialists.

Given the wide range of competencies required, finding the right person for the job can be challenging. During the MVP stage, when numerous pressing issues demand attention, the decision to hire a CTO can be overlooked. However, as your startup progresses beyond the MVP stage, effective technological management becomes crucial, especially when addressing any technical debt accumulated during the initial product phase.

What are the most important qualities of a good CTO?

**A leader in technology** 

The CTO plays a critical role in making architectural decisions, ensuring infrastructure scalability, and selecting the most effective tools to achieve both client and company objectives. They may also have greater control over the implementation of tech solutions. 

**Research & development for innovative solutions** 

The CTO holds a unique position in driving innovation by defining key directions for technological advancements. They inspire and motivate teams to think creatively, fostering an environment that encourages innovative ideas and thinking outside the box. 

**Hiring Talent**

Finding qualified candidates in the IT industry can be increasingly challenging. Involving the CTO in the recruitment process for development teams can enhance efficiency and satisfaction for both parties, as they possess the technical expertise to identify suitable candidates. 

**Product & development**

As the representative of the tech team, the CTO must effectively demonstrate how innovation and technology align with customer needs. Collaborating closely with the Chief Product Owner, the CTO ensures the creation of tech-enabled products that meet market demands. 

**Business & technology enabler** 

Working closely with both the in-house tech team and clients, the CTO serves as a bridge between business requirements and technical execution. Their deep understanding of both domains allows them to effectively translate business needs into a comprehensive technical plan.

Having identified the key qualities of a competent CTO in a startup, let us now shift our attention towards examining the benefits and drawbacks of employing an in-house candidate versus opting for the expertise of an external specialist.

#### **Pros and cons of in-house CTO** 
The in-house solution for a CTO has its own advantages and disadvantages. On the positive side, having an in-house CTO provides proximity and familiarity with the organization, but it can be costly. It is particularly beneficial for complex projects involving big data, AI, or large data volumes, whereas it may not be cost-effective for less advanced applications. 

An in-house CTO holds a crucial role within the organization as they possess extensive knowledge of internal processes, strategies, and the target market for product development. This internal perspective fosters a sense of organization, motivation, and deep involvement among team members. Furthermore, this model offers the advantages of high flexibility, simplified organization of agile workflows, and reduced response times for quick issue resolution.

![ ](\uploads\Blog-post_recyklning_ebooka_01_post01_3Ee3fEqUXYzqHJZIusGPIv.png)
#### #### **Pros and cons of CTO as a Service**
CTO as a service provides several advantages and disadvantages. The outsourced CTO is responsible for managing your company's technologies, engineers, IT support, and tech partners, ensuring proper diligence operations. They can work on a part-time, full-time (for a specific project or the entire company), or hourly basis, offering flexibility in decision-making. CTO outsourcing services are particularly beneficial for medium and small companies that don't require a permanent CTO but still need temporary leadership and technical supervision during specific software development cycles or for developer teams. Additionally, CTO as a Service is generally more cost-effective than hiring a full-time expert.

![ ](\uploads\Blog-post_recyklning_ebooka_01_post02_2IDrEsR6eIvGLMp07rarvM.png)

Naturally, the process of hiring a competent CTO poses its own set of challenges, and this blog post may not provide a definitive answer regarding the ideal CTO fit for your business. However, it can certainly help you evaluate the stage of your journey and identify experts best equipped to assist you in progressing further. Several crucial considerations need to be made when determining the type of CTO you require and the necessary skill set: 

1. **Business partner or technical manager:** Do you need a business partner with technological expertise to scale the business, or someone solely focused on managing the technical aspects without involvement in other areas of company development?

2. **Development stage:** Is your business in the early stages, requiring process organization and alignment of business goals with technology? Or are you post-MVP, seeking someone to plan and lead further technological development while building a reliable team? 

3. **Future goals:** If you plan to outsource part or all of your technological team in the future, an in-house CTO would be advantageous. However, if you already have a skilled team and only require part-time technical leadership, CTO as a Service may be sufficient. 

4. **Budget:** Consider the financial resources you are willing to allocate to the CTO position. 


Once you have determined the ideal solution for your organization, you can begin searching for suitable candidates or outsourcing services. 

___
#### **Summary** 
In this blog post, we explore the role of a Chief Technology Officer (CTO) in startups and scaleups and discuss the decision between hiring an in-house CTO or using a CTO as a Service. A good CTO possesses leadership in technology, drives innovation, helps in hiring talent, oversees product development, and acts as a bridge between business and technology.

Having an in-house CTO offers proximity and familiarity but can be costly, while CTO as a Service provides flexibility and cost-effectiveness for smaller companies. Factors to consider include whether a business partner or technical manager is needed, the development stage of the business, future goals, and budget.

Ultimately, finding the right fit for your organization requires careful consideration. Once you determine the ideal solution, you can start searching for suitable candidates or outsourcing services.

If you found this article interesting, we invite you to explore our ebook tailored for CEOs, founders, and product managers. It offers invaluable insights into the product development process, providing you with valuable knowledge and expertise.

[Link: The Product Journey: building application that scale](https://theproductjourney.bitnoise.pl/#form)




small_how-does-remix-enhance-hydrogen-shopify-front-end-development-framework.png

thumbnail_how-does-remix-enhance-hydrogen-shopify-front-end-development-framework.png

how-does-remix-enhance-hydrogen-shopify-front-end-development-framework.png

CTO as a Service or in-house CTO? Which is best for you?