Torc blog

Insights and resources from Torc leadership, the Torc community, and industry leaders.

Green illustrated design elementBlue illustrated arrow design element

Originally published on VentureBeat.

For a prime example of an industry successfully leveraging statistics to reward performance, look no further than baseball.

America’s favorite pastime has the most specific data sets of any sport, said Michael Morris, cofounder and CEO of Torc, a new software developer talent marketplace. Players are ranked on everything from batting average, to home runs, to RBIs (runs batted in).

There is significant opportunity to create this same sort of data-and-metrics-based performance leveling field for developers, Morris said.

“It’s not about where you came from, or what you look like that establishes how good you are — it’s how you perform,” Morris said. “It takes out bias, provides an opportunity for learning.”

It’s no secret that there’s a significant shortage in IT talent. Experts and executives alike have been decrying it for years. And, it seems, the problem could get worse. By 2030, more than 85 million jobs could go unfilled due to a dearth of qualified candidates, according to consulting firm Korn Ferry. This could translate to about $8.5 trillion in unrealized annual revenues.

AI connects developers with employers based on productivity

Torc says that it can offer a solution, and one that goes beyond just matching resumes with enterprise needs. The company has created an AI-driven platform that first connects developers with jobs based on numerous factors, then measures and compensates them based on their productivity and performance. Torc publicly launched its platform today.

“We’re passionate that developer productivity is the metric that should determine what a developer is worth,” said Morris. “That’s not necessarily the time spent sitting in a chair or typing on a keyboard, it’s the amount of time they spend producing.”

Users work directly through the platform so that Torc’s underlying technology can capture data and establish metrics on their productivity. When first signing up, users provide typical applicant information such as work goals, previous jobs, self-identified skill sets and programming languages that they are familiar with. Users are then sent through screenings and tests to establish their fluency in, say, Python or C++. These sessions are recorded and provide baseline scores. All this is then compiled to create a “rich” developer profile, Morris explained.

“This allows us to get a good view into somebody,” he said. “We can create new earning opportunities, give them access to jobs they traditionally wouldn’t have been given access to.”

He noted that all this is built upon a strong backbone of security. To verify the identities of workers on the platform, for instance, Torc is leveraging features around facial recognition to match them with their government-issued IDs. And because they work directly in the Torc platform, the company can shut down their access in the case of any security infraction or protocol breach.

Still, Morris noted that Torc doesn’t want to “overemphasize or become robotic” about data. It’s important to find the right cultural fit, too. Relying on human feedback as well as the AI component, the company can determine what workers and would-be employers are looking for when it comes to workplace culture and team dynamics and goals.

“We realize that the performance of an individual has a lot to do with the team and the company they’re working with,” Morris said. The gig economy software expert, who held previous leadership roles at Topcoder and Cloudspokes, has seen firsthand the power of building developer communities. Fueling interaction through peer groups “creates a lot of synergies, environments to have fun, to learn, to earn.”

Finding the right developers at the right time

Having spent his career in software development marketplaces, he also understands the ongoing challenge of accessing the right developers for the job. Needs can fluctuate with time as companies experience growth and expand their products or services. As this occurs, he pointed out, they may move into realms requiring different expertise than that of their existing talent.

“It comes down to, ‘What does the next platform of work look like for software developers?’” Morris said.

As it works to answer this question, Torc is supported by Recognize, a private equity firm led by Frank D’Souza (former CEO of Cognizant), Charles Phillips (former president of Oracle), and Dave Wasserman (former head of tech practice for Clayton, Dubilier & Rice), along with Rob Biederman, co-founder of Asymmetric Capital. Recognize and Asymmetric are committing an initial $5 million as part of Torc’s launch, with more significant capital planned, according to Morris.

Tech veteran D’Souza underscored the conundrum in the industry. “There’s never been a time of such dramatic innovation,” he said — yet the shortage of tech talent is constraining potential. Torc’s platform can have great implications in this area, enabling companies to tap historically underrepresented talent pools and reach a wider global audience. This, in turn, can bolster broader economic prosperity, he said.

As of Torc’s launch today, there were more than 1,400 developers on the platform, representing a threefold increase over the last two months, according to Morris. One of the first projects Torc is helping to facilitate involves Python data science work for NASA.

The majority of the company’s R&D has been focused on understanding productivity and deriving deeper insights from the data collected in that area, Morris explained.

Post-pandemic, Morris said he hopes the tech industry doesn’t slide back on the strides it has made around the gig and freelance economy. Companies should continue optimizing their operations around online work and broadening their mindset from a purely geographic standpoint when it comes to recruiting talent. It’s “nice, but not a must” when you can have people physically together, he said; organizations can benefit most when they look for the best possible match out there — regardless of where or who those workers may be.

“You have that choice in building a successful organization today,” he said.


How to hire developers using performance metrics

Torc CEO Mike Morris and Chair of the Board Frank D’Souza spoke with Taryn Plumb of VentureBeat about the launch of Torc, how software development should be more like baseball, and how Torc helps companies to solve their talent gaps.

Close up image of a person's hand touching an iPad tablet with a dashboard on the screen. The image is overlayed with several colorful illustrated design elements and the VentureBeat magazine logo.

I recently tried out and found it to be an absolute pleasure to work with, and extremely productive as well. My initial reaction of "This is just another competitor of NextJS" quickly turned into "Wow! This is so cool!" when I realized exactly what Remix is all about. When I finally recognized the beautiful design choices baked into Remix, I recognized them for what they are: pure genius.

Remix unifies the backend and the frontend

Remix mixes backend and frontend functionality in the same file. But that's not all it does–it then provides a simple way to transfer data to the frontend using hooks.

As simple as this sounds at first, it is revolutionary in terms of its impact.

Before I wax poetic about it, here is a code sample from one of Remix's two official tutorials. Notice how the posts loaded in the exported `loader` function are easily available in the React component using the `useLoaderData` hook.

Source: Remix. Markup by Torc.

This is huge.

We no longer have to do any of the activities below—Remix's loader abstraction handles all of it for us. The amount of saved time & effort is phenomenal.

  • Create an API utility function that contains the GET call for the `getPosts` controller
  • Write the backend controller that handles the GET call
  • Write a route for the controller
  • Manually test that the API util function works against the controller
  • Manually synchronize any future route changes between FE and BE
  • Manage multiple files for backend code, which breaks flow states

Right now, we all do this stuff over and over again, for no good reason. In fact, we're so used to it, we don't even think about it – it just feels like "part of the way we've always done things.

Not only is this a lot of saved effort, but it also leads to greater levels of flow state than previously possible. Remix fixes this problem so nicely that the old way of doing things now feels icky and unnecessary.

But what about separation of concerns?

Separation of concerns is good, right? If the frontend and the backend get mixed into one file, that causes all sorts of issues, right?

Well, once upon a time, developers would write HTML, CSS and JavaScript in different files.

Then, React came along and revolutionized the way frontend developers thought about frontend architecture. React pushed the use of JSX, which recommended that HTML and JavaScript should live in the same file.

That made a lot of people very angry. Team leads and architects railed against how JSX completely went against traditional separation between HTML and JS, and banned React from their projects. Many early teams rejected the idea outright because it went against the way they had always done things. Mixing HTML and JavaScript was a very controversial design decision at the time.

However, it soon became very clear that blending HTML and JS in the same file was a very large improvement in terms of productivity. All of a sudden, developers were much faster when it came to implementing complex JS behavior. And they enjoyed it a lot more, too.

This was because JSX, by keeping all related code in one place regardless of whether it was HTML or JS, reduced context-switching. We no longer had to juggle multiple files when dealing with JS and HTML. This, in turn, greatly improved the ergonomics & developer experience of working with React. This approach proved to be so popular that eventually, many of us started mixing our JavaScript and CSS in the same file as well, thanks to CSS-in-JS.

All in all, JSX made it possible for developers to become much more productive and enter into deeper flow states, for longer periods of time, because of better unification between layers.

Remix boosts productivity by unifying and simplifying the frontend and the backend

Remix takes this JSX philosophy a whole lot further by allowing us to mix backend and frontend code in the same file.

For the first time ever, I was able to code an entire page, from the database to the request handler to the React component and the CSS, in a single file. It obliterated the separation between frontend and backend that we're so used to, and brought forward a brand new sense of unity and flow that I hadn't felt in a long time.

That in itself is a huge achievement, but Remix doesn't stop there. It also offers a beautiful way to build nested components which are connected to the backend via Remix's loader abstraction, so that backend-connected layouts are also easy to build without having to context-switch into the backend.

On top of all of this, Remix somehow – impossibly – manages to make frontend development simpler instead of more complicated. Until now, web frameworks have consistently made web development more complex, not less. But Remix brings back plain HTML and manages to keep things simple. Even Remix's forms are essentially plain HTML forms, and are a pleasure to wire up to the backend. Goodbye, complicated React form libraries!

With built-in support for environment variables, multiple runtime environments, file routing, Typescript, and more, Remix also fits the same niche as NextJS. It has all the makings of an amazing framework and a worthy evolution building on top of the spirit of NextJS. I can't wait to dive into it again.

Learn more about hiring a Remix developer to simplify your next project.

Tech Review
min An underrated paradigm shift

Remix mixes backend and frontend functionality in the same file. But that's not all it does–it then provides a simple way to transfer data to the frontend using hooks. As simple as this sounds at first, it is revolutionary in terms of its impact.

Remix logo on a light green background. The image is overlayed with several colorful illustrated design elements.

Next.js was created by Vercel six years ago back in 2016. But in those six years, its popularity has grown massively (along with the popularity of Vercel as a deployment option) and it has quickly become one of the most popular React frameworks. It has almost 100,000 stars on GitHub and millions of downloads every week on NPM.

Its popularity is due to how easy it is to use. To create a fully-working Next.js app all you need to do is run:

This gives you a fully functional isomorphic (capable of rendering both on the client and server) app. Additionally, it has a wide variety of features to extend its capabilities.

However, there are problems with Next.js that have revealed themselves as it has continued to age. The build process is not optimized, reducing developer experience, and it uses outdated standards. This is why frameworks like Remix have been created.

Remix is a newer framework created by the team behind react-router in 2021. It aims to solve many of the problems that Next.js had, including build speed, adoption of modern standards, and separation of client and server code. Due to being created by the people that created react-router, it also includes more advanced routing features like nested layouts. It has tens of thousands of downloads every week on NPM, but trails behind next quite significantly:

Which should you be using? That depends a lot on what you want to do, but here we’re going to compare the two as if we’re building a markdown-based blog, a common need for js frameworks. We’re going to compare Next.js and Remix across the following features:

  1. Ease of setup
  2. Build process and compilation speed
  3. Ecosystem support
  4. Markdown & MDX support
  5. Extendability
  6. Developer experience
  7. Deployment

Let’s get to it!

Ease of setup

Next.js and Remix both have really straightforward setup processes.

For Next.js, we run the command above:

To get a working skeleton app. But Next.js has a huge template library that you can use to add more functionality to your app from the start. To create a new app with any of these you just run the above command with the—example flag and the template URL:

So if you wanted to include tailwindcss into your app from the get-go, you run:

You can also use flags to support TypeScript, eslint, or NPM explicitly.

Remix also has an easy setup and plenty of configuration options. Setup is:

And again you can use a template:

Remix has stacks (such as the indie stack above) and a helpful setup flow where you can choose JavaScript or TypeScript and your deployment target, such as, Vercel, or Cloudflare (obviously the Next.js setup presumes a Vercel deployment).

As you can see, they’re both super easy to set up, so we’ll call this a tie.

Winner: Tie

Build process and compilation speed

The build process is how the framework transforms your code into something the browser understands.

When building a blog, you generally do not want to wait long to preview posts, especially when you did not change any code other than the post itself. Because of this, the build process is important.

If you were comparing Remix to a past version of Next.js like Next.js 11, this would easily be in Remix’s favor. Remix has its own bundler (which uses esbuild under the hood) optimized for ESM (ECMAScript Modules), whereas Next.js uses Webpack, a bundler known for its performance issues.

The problem with Webpack is that it was built before the standardization of ESM, a module system built for browsers, and has not adapted to it enough yet. While Webpack supports ESM, its architecture means it must bundle everything instead of utilizing ESM, even if you are running the app in development mode. On the other hand, Remix’s bundler is built for ESM.

However, Next.js has improved in this aspect. It has recently adopted the Rust-based compiler SWC (Speedy Web Compiler) instead of Babel, which significantly improved performance. Additionally, Vercel is working on creating a new bundler called Turbopack, which should replace Webpack in the future and will likely fix most or all of the performance issues present here.

Source: Turbo

However, as of Next.js 13, it is still in development and does not support building for production.

Another thing to note is that Remix’s bundler does not support HMR (Hot Module Refresh), which updates components in development mode without a page refresh, maintaining the state of the page.

Overall, Remix is currently ahead of Next.js when it comes to production and development compilation speeds. This could change very soon due to Turbopack appearing in Next.js 13.

Winner: Remix

Ecosystem support

Ecosystems are key for efficient building. If there is already a library that provides what you need, that is one less thing on your plate. If you are building a blog, you need CMS support, image support, featured post support, and so on. Remix’s ecosystem is growing, but Next.js’s is bigger by a large margin, simply due to its age and popularity.

As of publishing, there are only 180 packages on NPM tagged with remix, as opposed to 1217 packages tagged with nextjs. It is not even a contest. While this might change in a few years, currently, Next.js easily wins.

The caveat to this is the support for expansion that Shopify is going to bring to Remix. Shopify bought Remix in October 2022 and it is going to become an integral part of the Shopify ecosystem. This means that developing for Shopify means developing in and for Remix, so expect to see more remix-specific packages coming through and the ecosystem being built out with help from Shopify.

Winner: Next.js

Markdown & MDX

Markdown is the most popular way for developers to write long-form content (in fact, this article was drafted in Markdown), so it is crucial for a blog. Both frameworks support markdown and extensions such as MDX. However, there still are a few differences.

First, the setup process for MDX is a bit different between Next.js and Remix. To set up MDX in Next.js, you need to install their @next/mdx plugin and add it to your next.config.js. On the other hand, with Remix, MDX support is built in, although if you want it rendered dynamically rather than just being precompiled, you will need to use something like mdx-bundler.

Another difference is how they handle frontmatter. Frontmatter is data you put in a Markdown file that describes the file. For example, you might put in a title, tags, and the author name. The format Remix and Next.js use are pretty different. Remix uses a more standard frontmatter format, where you put YAML in between ---:

On the other hand, Next.js allows you to export an object using ESM. This is not the standard way of adding frontmatter in Markdown, but it might be more familiar to people used to JavaScript.

You can use YAML or TOML with Next.js, but it requires a separate frontmatter processor and a fair amount of setup to get it rendered. Overall, we have to give this point to Remix because you can use MDX without a plugin, and the frontmatter format is on point.

Winner: Remix


Extending the capability of a framework/build tool is very important for a project like a blog because you want it to be as easy as possible to write blog posts.

This might mean adding a plugin to automate some elements of creating a blog post or creating a new syntax feature to enable more concise implementations of certain things within a blog post. Unfortunately, while Next.js has good plugin support, Remix is lacking in this aspect.

Because Next.js uses Webpack, you can use any of the wide variety of Webpack plugins in a Next.js project. The Webpack configuration format can be complicated, but once you get the hang of it, you can do a lot. You can also add SWC plugins to customize the compilation itself, although SWC’s plugin support is experimental as of now. However, we have yet to see how plugin compatibility will be once Next.js migrates to Turbopack.

On the other hand, Remix’s bundler does not support plugins at all. You can still do quite a lot by adding separate scripts to run whenever you compile your project, but that is a lot less elegant.

Winner: Next.js

Developer experience

DX is more subjective, but there are still some universal differences.

Remix is less abstracted than Next.js, which can be good or bad depending on how you view it. On one hand, you might need to write more code, but due to Remix’s adherence to web standards, you might be more familiar with the methods to write that code. It also means that your code is potentially more reusable and more future-proof.

Remix also includes some helpful hooks like useFormAction. However, these do not impact overall ease of use much, because they are only applicable in specific cases and you can use a third-party library anyway.

Next.js has a lot of infrastructure set up to help you use the framework, which is a positive for the developer experience. The flip of this is that the framework is large, making it more difficult to understand from a cold start and as it tries to be all things to all people,

Basically, both have positives and negatives in their DX, so we’re making this a tie.

Winner: Tie


Both Next.js and Remix have a variety of deployment options. With both, you can deploy to a Node server to run a traditional VM as well as edge serverless function platforms.

Next.js allows you to deploy to Node.js servers using next build, static HTML using next export, and you can use third-party plugins to deploy to popular serverless function providers. On the other hand, Remix has integrated tools to deploy to serverless targets and allows you to select them in the setup CLI.

However, Remix has one crucial limitation: You are unable to use Static Site Generation (SSG). That means you are unable to generate static HTML files to put on a file host, reducing the deployment options you have.

In this category, Next.js wins, because static site generation is an important feature, especially for websites like blogs (although Remix’s philosophy is that it is unnecessary).

Winner: Next.js

Comparison table

Comparison table


If you tallied up the comparison, you probably noticed Next.js was ahead in one more category than Remix. However, comparisons are never this simple, and a lot of it depends on your priorities. Here, we’re focusing on blog-building and Next.js is the better option for that. The static site generation it offers helps get the most performance out of a website, and we like the extensibility of Next.js.

However, If you prioritize adherence to web standards, Remix is a better choice. Also, if you are going to be building a site that can take full advantage of the server-side rendering Remix offers, like an ecommerce site, the choice is a much closer one.

But if you want the most well-known framework, Next.js is the option to choose. You can build the blog, the rest of the marketing site, the admin panel, and the entire application with Next.js

The takeaway from this article though is Remix is pushing Next.js, as Vercel themselves admit:

Image of a tweet
Source: Twitter

This competition is excellent for developers. It means that there is more choice, but also that each framework has to continue to improve to survive. As Lee Robinson says: Developers Win.

Learn more about the remix framework or how to hire a remix developer.

Tech Review

Should you build your blog in Remix or NextJS?

Are you thinking about building a blog but are unsure of which tech framework to use? NextJS and Remix are two of the more popular frameworks for this application, and each has its own benefits. Ultimately, it comes down to your individual priorities. Our full review compares NextJS and Remix across a range of categories, including ease of setup, build process and compilation speed, ecosystem support, markdown & MDX, extensibility, developer experience, and deployment.

Light orange background with the Remix and NextJS logos and multiple illustrated design elements

Torc CEO Mike Morris recently chatted with Forbes India's Harichandan Arakali about how Torc is changing the way companies find and work with great tech talent.


Forbes India Daily Tech Conversation

Torc CEO Mike Morris recently chats with Forbes India's Harichandan Arakali about how Torc is changing the way companies find and work with great tech talent.

Forbes Daily Tech Conversations podcast logo and an image of podcast guest and Torc CEO Mike Morris. The image is overlayed with several colorful illustrated design elements.

As an engineering leader, you're no stranger to business pressures, especially the kinds that force you to incur technical debt on your projects. You have built a nuanced understanding of technical debt as a valid and normal part of engineering philosophy. As business pressures fluctuate, you understand how to manage that debt and reduce it over time.

Culture debt

Interestingly, there is a sister of technical debt that rarely gets talked about, but affects your work very deeply. Culture debt is what happens when teams compromise on long-term culture in favor of short-term goals.

This takes many different forms: teams might decide to hire a lot of people very quickly to address immediate scaling problems. Or they might decide to overlook promoting-from-within in favor of hiring consultants to quickly solve a problem.

Like technical debt, culture debt is a valid and normal part of management philosophy and can be used effectively to achieve the team's goals.


Culture debt very commonly turns into Pretty Urgent Senior Hiring (a.k.a. PUSH). PUSH happens when a team sees the need to urgently build features, then decides that hiring a senior developer with prior knowledge of the domain is the best way to solve this problem.

Other ways to solve the problem might exist. For example, the team might have promoted or transferred an existing developer onto the urgent project, then trusted them to hire and train their own replacement on the old project.

New hires are always risky to culture; senior hires even more so. PUSH has many side-effects that, like any other type of debt, snowball over time when not addressed.

  • Skipping people for promotion or transfer will cause frustration or resentment.
  • Hiring for a single senior developer will take months, resulting in lost output.
  • Senior engineers will leave because there is no more room to grow within the team.
  • Junior and mid-level engineers will leave because promotion from within seldom occurs.
  • Morale will suffer as teammates leave (and take other teammates with them.)
  • Software quality will suffer as knowledge churns out of the company at a faster rate.
  • The lower velocity of delivery creates urgency, which means taking out technical debt.


When the debt caused by PUSH is left unaddressed, the problem takes on another tone altogether. Churn becomes so high, the rate of technical debt accumulation is so large, and velocity so low, that the team simply cannot hire enough developers to maintain velocity.

However, something must be done about the issue–so a culture of urgently hiring more seniors sets in. The team doubles-down on the PUSH strategy and begins hiring even more senior developers.

Chart describing PUSH and RUSH impacts

At this point, PUSH has turned into Rotating Urgent Senior Hiring (RUSH). The symptoms become more and more intensified.

  • Hiring seniors is seen as the only way to address velocity concerns.
  • Technical debt continues to build as knowledge drops and urgency rises.
  • Promoting and transferring internally slows down or completely stops.
  • The culture slows down and stagnates because of constant urgency.
  • It becomes impossible to hire enough senior developers to fill demand.
  • Over time, the company will start relying on 3rd-party recruiters to fill the gaps.
  • Over-reliance on recruiters eventually diminishes the ability and will to hire internally.

The way out of PUSH and RUSH

As an engineering leader, you are one of the few individuals who can have a large positive impact on the situation and turn it around. Using a combination of management wisdom and technical knowledge, you can re-stabilize your team and recreate a healthy environment in which a sustainable technical culture can be re-established.

PUSH and RUSH arise because of an urgency culture that has taken a hold inside the business. The need to hit urgent business needs makes us sacrifice long-term success for immediate returns. The right approach to fixing PUSH/RUSH will tackle urgency culture at its core while acknowledging that the issue will take some time to fix.

Some approaches that could work are:

  • Increase transparency between business and technical departments.
  • Renegotiate deadlines for large milestones.
  • Allow engineers to transfer between projects.
  • Create a level-based promotion pathway with appropriate incentives.
  • Promote engineers and replace them with intermediate and junior developers.
  • Acknowledge the senior talent shortage. Normalize hiring less experienced developers.

Culture debt: What it is and how it impacts business goals

As an engineering leader, you're no stranger to business pressures, especially the kinds that force you to incur technical debt on your projects. Culture debt is a sister of technical debt that rarely gets talked about, but affects your work very deeply.

A frustrated man sitting at a table looking at his computer with his hand on his head. The image is overlayed with several colorful illustrated design elements.
No results found.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.