Building a company for the second time (part 2)

In its inexorable path towards eating the world, software is embedding itself into the core aspects of business, enabling companies to operate more seamlessly and efficiently. In most cases, it's not a matter of "if," but "when" software will take over a non-software-powered step or function. You can probably name at least a dozen software products you use at your company in day-to-day operations: let's call this collection of software applications the company's Operational Tech Stack.

A subset of companies, those that build/distribute technology products or applications, also have a second (equally critical) tech stack that we'll refer to as the Software Development Tech Stack. This is a collection of programming languages, frameworks, and tools, and it serves as the ingredient list an engineering team uses to create custom applications (internal or external).

In general, these tech stacks are managed separately, by different departments, and the applications are unlikely to "talk to each other." Maybe because at Olapic we suffered the negative consequences of that separation, this time around we set out to build a much more interconnected system. This is likely to be one of the main reasons behind the rise of API-first or "headless" software. We also set out to take a completely fresh look at the landscape of tools and technologies available to us (rather than leverage what we'd used at Olapic,) and to prioritize flexibility and optionality to accommodate the unknowns of the future.

In Part 1, we explored the early customer discovery process we ran, and in our first investor newsletter, we hinted at Remotely's current "operational tech stack." In Part 2 here, we will take a deeper dive into the tech stack we're using at Remotely. Building a company for the second time around, 10+ years later, is a reminder of just how fast things move.

The building blocks

At its core, Remotely is about connecting talented developers with great opportunities. We're constantly building our supply (finding developers, qualifying talent, enriching profiles), and our demand (U.S. based tech companies looking to build an engineering hub abroad). Managing this ever-growing dataset, and setting it up in a way that it could connect to and power other systems, was of first-order importance. At a high level, we need to track and manage several data sets:

• Supply: profiling strong talent in the Remotely network (potential matches for companies) and their team relationships

• Demand: building a CRM with a directory of Companies, Sales Opportunities, Contacts, and Activities

• Operations: archiving our consulting agreements, our NDAs, and the invoices we pay developers. We also document the payment flows (with FX rates, commissions, and wire transfer IDs).

For this, we use Airtable, a cloud-based collaborative spreadsheet that allows for a broader array of fields than excel, a variety of views (e.g a standard table view, card-based, etc) and different options for data-input (e.g. forms, APIs).

We like Airtable over, say, excel, Google Sheets or a traditional database, because it perfectly fits our short-term, manual approach to operating Remotely (we do all the data input ourselves, updating records, etc.), but can be connected to other systems and built upon down the road.

We also believe that a more natural, streamlined, and high-bandwidth communication can help shorten the geographic divide and bring developers closer to the opportunities. To shorten the distance we use:

• Slack: for our 1:1 and 1:many internal comms, but also to communicate with our prospects, customers, and partners (via shared slack channels)

• Zoom: for team meetings as well as customer calls. Together with Grain, it becomes a documentation tool. Grain is fundamental for creating our Opportunity Memos: our version of "job postings" that include information that is actually useful.

• Loom: to provide high-bandwidth asynchronous communication. We use it to provide personal feedback on a meeting, a product feature, a document, or an idea. It's like a video voicemail, which we find helps humanize our day-to-day and cut down on miscommunication. But we also use loom to record walkthroughs on candidates and teams that our customers use for review.

Finally, Remotely is about getting people paid abroad. So, similarly, when selecting our financial infrastructure, we wanted a modern solution that would afford us the option to build on top of it:

• Mercury: for our banking in the US with no fees; Includes an API we plan to use in the future

• Transferwise: for our international wire transfers with great FX rates; also has an API

• Stripe: payment gateway for this newsletter

• Brex: corporate credit card provider with no fees

• Quickbooks: accounting software

• Carta: for investor relations, employee option pool, and capitalization table management

The connectivity of these tools is what makes the system worth setting up from the beginning: Quickbooks pulls data from Mercury, Stripe, and Brex; Quickbooks sends financial statement data to Carta automatically; Brex and Stripe connect to Mercury via Plaid; Mercury and Transferwise have APIs we can build on top of. And our outsourced accountant shares a slack channel with us through Slack Connect.

Discovering no-code

As we set out to build Remotely, we embarked on a journey with the intent of initially doing each step manually so that, over time, we could build tools (software tools) to deliver operational leverage to our activity. We ultimately planned to build a software tech stack and the tools or applications we needed to run the business, but a serendipitous encounter during our customer discovery process led us to rethink this approach.

I met Ariel Camus, founder of Microverse.org, a distributed, income-sharing coding bootcamp, who had recently graduated from Ycombinator and raised an impressive seed round. I was excited to learn how he had built his engineering team, but much to my surprise, a few seconds into our conversation he mentioned that he had avoided hiring engineers by implementing no-code tools.

No-code tools are software tools that, via plugins and other connector services, can be stitched together to automate simple, yet powerful processes without writing code. I was familiar with no-code, and intrigued, but had the impression that the value of these tools was in building discardable MVPs quickly. I was wrong. Through my conversation with Ariel, it became clear that the value of no-code goes far beyond temporal use-cases. No-code tools are fully capable of scaling with your user-base and becoming the rails of many products. This is particularly true for service-based products, like Remotely.

I came out of my conversation with Ariel with the intent of exploring no-code tools as the scaffolding of Remotely. Since then, we've begun building this scaffolding. No-code has afforded us the ability to iterate shockingly fast and at a low cost, but we're still just scratching the surface of its potential.

Stitching it all together

What makes no-code connectivity powerful is the possibility of using the data and output of one tool as input for another tool. For example, if you can use your CRM as the database that powers your web service, you can create and provide an account (for the web service) to a potential customer by simply creating a contact record in your CRM. In other words, no-code allows you to leverage the productivity tools you use as the backend of the service you provide to your customers. The two stacks that used to be separate are starting to blend together.

We use Integromat / Zapier to connect different tools, pushing data from Airtable out to other applications (filling up a contract with personal data of a developer that we store on airtable) as well as inputting data we collect in the outside world to enrich our CRM (e.g. feed the results of our website survey into our Companies database, and create a new sales lead).

The collection of tools we are using for different tasks keeps expanding:

• Typeform: for data gathering for companies and talent

• Pipplet: for English testing of candidates

• Pandadoc: for e-signatures of contracts and agreements

• Webflow: for our marketplace site and marketing page

• Substack: for our newsletter (this here!)

With this, you can connect your internal tools with the client-facing experience, without the need for programming a backend from scratch. Deeply integrating tools via no-code is enabling us to quickly iterate customer experience concepts and get customer feedback faster.

Open questions as we embark in this new journey

No-code has been an incredible benefit to getting Remotely off-the-ground quickly and effectively. But it raises new questions: if you are not building a codebase, what's your competitive advantage; if anyone can quickly stitch together tools that are cheap and readily available for anyone, what prevents copycats of your service from popping up everywhere?

Furthermore: what is the dependency on no-code long-term, how reliable are those platforms and how does it affect the value of your company; will we hit a glass ceiling that will hamper the growth of the company?