The modern workplace has fundamentally changed. It’s not just a result of the COVID-19 pandemic; employees are approaching work differently, interacting with one another differently, and viewing work-life balance in new ways.

Since Coda was founded, we’ve thought deeply about how work gets done, as well as how we can make work feel less like work. With the goal of gleaning insights into how people work together and how individuals complete their best work in 2022, we surveyed 1,000 full-time employees. Taking into consideration age, gender, and geographic location within the US, we asked a variety of questions centered on workplace proficiency and proclivity.

We found that work is personal. People prefer flexibility when it comes to when, where, and how work gets done. And employee satisfaction is correlated to how processes are adapted to preferences. Here are the details.

Meetings are the best way to brainstorm, but there’s still room for improvement.

Even if you’re anti-meeting, you have to consider the benefits of brainstorming face-to-face (or even screen-to-screen). Survey results showed that live forms of communication remain the most favored way to brainstorm. When asked how they prefer to brainstorm with coworkers, every responding age group reported in-person meetings as their first choice, followed by virtual meetings. Messaging platforms came third, and document collaboration was least preferred as a primary way to brainstorm. The overall takeaway is that the overwhelming majority (80%) prefer to brainstorm in some sort of meeting, whether that’s in person or virtual.

However, once you’re in the meeting, consider ways to level the playing field so that all attendees have an opportunity to meaningfully contribute. In our survey, women were 15% more likely than men to say that their input was not considered in meetings. To combat this, one of our favorite rituals at Coda is called a Dory, which is a voting table used to determine which ideas to discuss first. Instead of relying on round-robin conversation or defaulting to the loudest voice in the room, this helps ensure every person’s input is heard.

While not every meeting is created equal (there will always be those that could have been an email), it’s important for managers and team leads to source information like this to find out how their employees best collaborate in order to get the best brainstorm results. Whether your team is varied in age or concentrated in one generation, you may find that their preferences are different than you’d assume. This chart shows a strong preference for in-person brainstorms across all age groups, followed by virtual brainstorm meetings:

Kill your morning check-ins.

Across the workforce, many teams have implemented the “morning standup” ritual — scheduling a recurring check-in for 15–30 minutes every day to align on priorities and pressing deliverables. However, more than two-thirds of survey respondents (69%) are “morning people” when it comes to productivity, claiming they do their best-focused work during this time.

If this many of your employees are their most productive selves in the morning, it’s less efficient to schedule a recurring status update meeting during a time that disrupts the flow of their critical thinking. Instead, consider a few alternatives — maybe it’s a daily survey where they report on tasks virtually, or an afternoon standup to plan for the next day.

If you choose the afternoon standup, try to avoid scheduling it back-to-back with another meeting — more than half of survey respondents (54%) prefer whitespace between meetings in their calendar. Whatever you choose, make sure that you’re sourcing employee feedback so not as to interrupt their deep focus and to maximize time spent together. The preference is clear in this chart, which shows that most respondents prefer the mornings for focused work:

Email and to-do list management is highly personal — and that’s a good thing.

For years, it seems like tech companies have aimed to replace the idea of the email inbox: cut down the number of emails you receive daily, create a better way to organize or send emails, and create a communication tool that replaces email entirely. Try as they might, everyone still gets too many emails. 84% of respondents said they have many emails in their inboxes on a regular basis. This was most prevalent for those over the age of 35, who typically began their professional careers before the introduction of tools like Skype, Slack, and Google Drive. However, three-quarters of Gen Z employees also report having many emails on a daily basis. The chart below shows that only 13% of respondents have very few emails in their inbox, and just 3% of respondents are able to skip using email entirely:

Given that context-switching from email to other apps costs time and focus, consider using quick communication tools for everyday tasks, asks, and updates. Save email for big-picture items, external communication, and longer-term outlines that may otherwise get lost in the high volume of instant messages. Alternatively, aim to conduct work outside of standard email, and take advantage of the customizable features of tools like Coda, where you can collaborate in a way that’s most convenient for you. For example, using suggest changes or creating a personal view of your task list will save at least a few email back-and-forths.

Shishir Mehrotra, our cofounder and CEO, believes that to-do list makers fall in one of two camps: they are “etch-a-sketchers” and start a fresh to-do list each day, or they are “pilers” and continually add to an existing to-do list. Our survey found that more than half of respondents (56%) edit an existing to-do list each day. Only 22% of respondents start a new list each day, and just as many respondents say they do not keep a to-do list at all. Regardless of your to-do list preference, it’s important to choose a to-do list system that is personalized to your preferred way of working.

More productive people: they’re just like us!

When survey respondents compared their productivity to their coworkers, 41% of respondents believe they are more productive than their counterparts, compared to just 8% of respondents who believe they are less productive than their coworkers. Men are more likely than women to self-identify as more productive (57% of men compared to 43% of women), and Gen Z is less likely than other age groups to report that they are more productive, but that’s where the differences end.

This cohort of “more productive” employees has the same preferences as everyone else when it comes to doing their most productive work during the morning, afternoon, or evening. They are just as likely to forgo a to-do list as those who say they are less productive or as productive as their colleagues. They also have the same meeting scheduling preferences. This tells us that productivity really boils down to personal preferences and when workplaces offer flexibility, employees feel more empowered to do their best work.

Most notably, regardless of working in an in-person, hybrid, or remote location, productivity perception remains nearly the same:

These similar productivity levels contradict the perception shared by some executives who believe that people should return to the office in order to be more productive. If productivity is indeed the same regardless of work location, organizations should offer workplace flexibility and embrace personal work styles, where possible, in order to increase employee satisfaction.

So where do we go from here?

If employers want to combat quiet quitting, low employee engagement, and burnout, they need to understand their employees’ preferences. To start, take into account the time of day when team members feel they get their best work done, their preferences for scheduling meetings, their preferred way to brainstorm, and the tools needed to support all of the above.

And that’s why Coda is the doc for teams. We’ve built Coda with these basic requirements for productivity — and we believe that tools should flex to the team instead of the other way around. Here are a few ways you can build a more personal workspace for your team in Coda:

• To ensure everyone’s voice is heard in the meeting, try a Dory.
• To optimize the time spent brainstorming — even if it’s not in person — try this brainstorming template.
• To skip the morning check-in altogether, try this team hub template with space for status updates.
• To see what makes your team tick, encourage them to fill out this blueprint doc.
• To manage your to-do list, whether you pile on or start fresh each day, try out Shishir’s to-do list doc.
• To cut down on the volume of emails, try this project tracker that automates sharing status updates in Slack.
• To stay connected with coworkers even if you all work remotely, check out a few pointers from our remote work toolkit.

Methodology

From June 23 — August 28, 2022, we surveyed 1,002 full-time employees in the U.S. who work at a computer and often with a team. We surveyed people ranging in age from 18–64. 49% of respondents were male and 51% of respondents were female. The survey was issued twice, with the second survey identical to the first survey, except for two additional questions: “Which of the following best describes the physical location where you work?” and “What is the biggest problem with meetings you attend, if any?” Because of this, the response volume for these two questions is significantly lower, with 594 responses. For all other questions, survey response count ranges from 997 to 1,002, where survey response count is slightly lower for questions that were asked later in each survey.

Fair Use: Feel free to use this data and research with proper attribution linking to this study.

Media inquiries: For media inquiries, contact Rachel Colson at press@coda.io

Survey: Rituals of the modern workplace are highly personal was originally published in Coda Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Explore this post as an interactive Coda doc here.

Running a great interviewing process has been a critical success factor for organizations throughout my career, from academia, through building multiple large teams at Google (Gmail, YouTube, Google Shopping, Google Travel), to leading the engineering team at a Silicon Valley startup.

In an ever-growing company, the amount of time employees spend interviewing potential candidates can be pretty high. The Coda engineering team has designed our interview process to distribute the lift across the team fairly, efficiently, and flexibly. We achieve that by designing for efficiency and flexibility, and by load balancing at two stages.

If you want to use our process and adapt it to your needs, we are happy to help you set up your own Interview Load Tracker in Coda. Just contact us.

Designing for efficiency

In a high-capacity interview process, it’s incredibly important that interviewing is efficient. We believe that training new interviewers should be easy and fast, interviewers should be well calibrated for their interview so that their feedback has maximum impact, and that the overall process should be as short as possible to make a decision.

Given these needs, we use a standardized process for hiring engineers where every candidate for the same role gets the same interview questions, and interviewers specialize in a single interview question. This strategy creates higher quality interview feedback, as the pool of interviewers is smaller, and individual interviewers see more candidates solve the same problem. We also invest some thought into fitting the interviewer to the right interview type. And of course, if an interviewer gets tired of their interview, we rotate them to a different one.

Each interview question has a scoring rubric, a person who handles training new interviewers, plus a Slack channel for the interviewers to calibrate in situations not covered by the rubric and training. Also, each hiring decision maker is assigned one of the questions. When they read all the interview feedback, they pay extra attention to the quality of the feedback for their question and provide (positive or negative) feedback to the interviewers as needed. Here’s an example of what that rubric looks like:

Designing for flexibility

In addition to being efficient, the process also needs to be flexible. It might sound fair for everyone to spend the same number of hours interviewing each week, but that would be too rigid in many circumstances.

First, while we have a target interview load for all interviewers, we can reduce the load for individual interviewers to factor in all kinds of circumstances, ranging from their project load, working part-time, or anything that impacts how much of their time they should dedicate to interviewing.

Second, to encourage a reflection of real-world circumstances, we balance our interview load over a rather long period of 90 days. By expanding the time scale past weekly or monthly, we give our engineers the freedom to take leaves for illness, childcare, or vacation, without this creating havoc to their interview load afterward.

Stage one balancing

We use a Coda doc to manage the entire interview process and all interview information. That doc includes a table with all interviewers and the question they are assigned. In one table, we can control interview load from 0 to 100% to account for long-term circumstances why someone’s load should be reduced. In another, we track new hires and their start date and can add them as interviewers and assign their interview question. As a nice feature, the new hire table will flag if they still need to be trained, so the person running interview training can set up that training.

The table to manage interviewers

A table to add new hires to the interview process.

A key question at this stage is how many interviewers to assign/train for each interview question. This is where the first stage of load balancing comes in (Interviewer Assignment).

We can play with hiring targets and their implications for our interviewers on this page. Critical input data here is how many interviews of each type are needed for a successful hire (as determined by the interview funnel and offer acceptance rate). Even if you do not have these numbers at hand, Coda has integrations with tools like Greenhouse that can help.

Factoring in the different efforts (and duration) of the interviews, our doc calculates the optimal number of interviewers for each interview question. Then, it compares the optimal number of interviewers to the current pool of interviewers to show gaps in coverage. This function lets us know how many people to train for which question.

The outcome of stage one balancing is that each pool of interviewers is the right size so that interviewers spend roughly the same time interviewing no matter which pool they are in.

Stage two balancing

In the second stage of load balancing, we need to assign the right person to the next interview that is being scheduled, taking into account who is trained for the interview and who has the least load. For that, it’s necessary to pull in accurate snapshots of our interviewers’ schedules.

Our doc is doing that by using the Google Calendar Pack, which allows us to pull in all scheduled interviews from our interview calendar and match them to our interviewers. Like many Coda projects, this was easy to build, yet powerful. When our recruiters go to schedule an interview, they see the table below, always in sync with Google Calendar:

The doc shows all interviewers grouped by interview question and sorted by who should do the next interview. Who “should” be the next interviewer is determined by their expected interview load, as well as how many interviews everyone has done in the last 90 days and how many they are scheduled to do in the next four weeks.

When a recruiter needs to schedule an interview, they invite the interviewer at the top of the list for the interview type. If that person is not available on the day needed, the recruiter picks the next interviewer on the list. This ensures load balancing over a sliding window of 90 days (factoring in future scheduled interviews). The tool also marks if someone has a massive number of interviews in the next four weeks or the last 2, allowing the recruiter to reach out before setting up more interviews.

We could have used several out-of-the-box tools to run our interview process, but we found that the flexibility of our Coda doc allowed us to build a tool that uniquely fit the team and our need for transparency, flexibility, and efficiency. If you are interested in optimizing your interviewing process, the team and I are very passionate about this area and are happy to share our doc and help you with it. Do not hesitate to reach out.

Interview load balancing: How Coda’s engineering team scales fast was originally published in Coda Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Like it or not, remote work is here to stay.

No matter what kind of approach your company has decided to take, one thing we can all probably agree on is that COVID-19 has changed how we think about work and how we work with others.

Question is: How can we optimize our new working patterns, beyond creating nice work from home spaces?

We’ve always known that good communication is a key characteristic of high-performing teams. Years ago, before hybrid teams were even a thing, the Project Management Institute (PMI) reported in its Pulse of the Profession™ 2020 study which claimed the following:

‘On average, two in five projects do not meet their original goals and business intent, and one-half of those unsuccessful projects are related to ineffective communications.’

With a growing number of teams transforming themselves into hybrid, globally dispersed, or remote-only versions of themselves, the need for solid communication strategies and practices is greater than ever.

So, where can we turn for insights and best practices? Maybe our friends in marketing can help.

Think like a marketer.

As someone who’s hung out with marketing and content strategy teams a lot in the last few years, I’ve found that marketers always seem to know the right thing to say at the right time, in the right way, and to the right group of people.

When researching the topic of ‘communication and remote teams’, one particular quote from Shel Holtz caught my attention:

“It’s time for employee communicators to start thinking like marketers, delivering the right information to the right employee at the right time through the right channel.”

So, how do marketers think?

Pick up any marketing textbook, and you’ll eventually come across the concept of marketing mix. It’s one of the most enduring and widely accepted frameworks in the field, first introduced by a Professor of Marketing at Harvard University back in the 1940’s named James Culliton in his book, The Management of Marketing Costs. Some 20 years later, his work resurfaced with Jerome McCarty, who gave it a much catchier name by branding it the 4 Ps.

The 4 Ps of marketing are: product, price, place, and promotion.

It was then transformed into the 4 Cs in 1990 by Robert F. Lauterborn, who replaced each of the p’s with more consumer-focused concepts that start with the letter — you got it — ‘C.’

• Product became consumer
• Price became cost
• Place became convenience
• Promotion became communication

A focus on people, not things.

In the same way that the 4 Cs remind marketers to always start with a clear understanding of the people they’re marketing to, we should start with a clear understanding of our teammates we’re communicating with.

The following table is my best attempt at translating Lauterborn’s Marketing 4 Cs into the context of team communications. I’ve taken the liberty to rename the marketing 4Cs so they refer to concepts more relevant to team communications. To me, it makes more sense to refer to our teammates as ‘colleagues’ rather than as ‘consumers.’ I’ve also opted for the term ‘connections’ to highlight the essence of the ‘communication’ principle, as described in the 4 Cs.

The 4 Cs remind us that marketing, done well, is built on a deep knowledge and understanding of others. This discovery phase takes place before you start drafting any messages, propose any new feature, or launch any new campaigns.

I believe this kind of approach is also true for developing good communication within teams.

How to incorporate the 4 Cs of team communication at work.

The phrase, ‘there’s no I in team’ is often used by leaders and coaches at kickoff meetings or huddles to get teams to work together better — to help them move away from an individualistic mindset to more of a group-centered one.

Team communications starts with a focus on others — what they need, what they don’t need, and when they may need to know. Let’s get practical and see how the 4 Cs can help our remote teams stay connected.

1. Colleagues: Find out what your teammates really want to know, need to know, and care to know.

Our default mode is often to say too much or too little.

Both can be just as ineffective because, it’s not so important the amount of information we communicate, but whether or not information is relevant and valuable in the eyes of our recipients.

With remotely distributed teams, many of our dynamic, in-person dialogues and spontaneous hallway chats are now replaced by video calls where people must take turns to speak, and make every attempt not to talk over one another.

These video calls have produced two different types of team dynamics:

• Individuals who attempt to optimize their airtime, leaving little or no time to solicit input from others to ensure their message is understood and useful.
• Individuals who attempt to give everyone a chance to speak up, leaving less time for themselves to provide some important context or share critical details about a project, announcement, or new proposal.

💡 Tip: Just ask.

• “What do you and others want to know?”
• “What do you think would be most valuable and relevant at this time?”
• “What are some things people don’t care to know?”

2. Cost: Remember that any communications you share with teammates is going to take time and effort away from their other priorities.

Have you ever heard someone on your team tell you, “I didn’t have time to read everything in your email…” or “I read your email, but didn’t quite understand what you were asking me to do…”? If so, this might be a subtle hint that your messages are either too long, too confusing, or don’t come across as relevant or important enough for them to read through. If you’re like me, maybe you’ve even sent messages like this — you know — the ones that require significant scrolling to get to the end.

Yeah, don’t do that.

Over time, I’ve learned that people will either not respond to a long message like that, or are very delayed in their responses. It’s not that people are trying to be rude. Often, it’s just because they’re really busy. In fact, people who work from home are spending longer time at their desks and facing a bigger workload than before the Covid pandemic hit.

Maybe some of us have also been on the receiving end of such emails and chats. So, what can we do to avoid these situations?

💡 Tip: Read your messages aloud before you hit ‘send’.

If you don’t already do so, try to develop a habit of reading emails aloud before sending them out. As you hear yourself reading, think about how your intended recipient(s) might respond to it.

Ask yourself questions like:

• Will the recipients walk away with a clear idea of what they need to understand or what they need to do?
• What aspects of the message will they most care about, or find most relevant to them?
• What might they not need to know right now? What can wait?
• Is any important information missing? Do we need to ask someone else to provide more?

💡 Tip: Keep it short and simple, with lots of whitespace.

One ‘business writing’ workshop I took a few years ago equipped me with skills I continue to use today. The key takeaway for me was to clearly state (in as few words as possible) why I’m reaching out and what I expect others to do.

Here’s the following 3-part format I continue to use to structure my emails:

1. Intro: After a short, one-line greeting, state your intentions.
2. Request: State my request, expectations, or questions clearly in the second paragraph in 2–3 sentences (with bullet points, if possible).
3. Wrap-up: Close with an optional, final paragraph (with no more than 3 sentences) that provides any relevant details or links (as bullet points).

We also learned the secret of adding line breaks between each paragraph to create lots of whitespace for easier scanning.

Finally, we were repeatedly reminded to review all our emails before sending them — either by reading them aloud to ourselves or inviting others to help us do a quick check.

There are two ways you can start incorporating this into your workflow:

• Keep important emails in a ‘drafts’ folder so you can read them over again to make sure they’re clear and succinct, before you click ‘send’.
• Create a system that keeps your email drafts organized so you won’t forget to review or send them. To try it out for yourself, check out my “look before you send” doc. It even lets you set up Gmails directly from the doc — with one click:

3. Convenience: Do your best to remove any barriers that could potentially hinder teammates from responding or acting upon your messages.

Out of all the best practices I’ve learned from my marketing friends, this is probably the one I find most helpful.

Marketers often talk about CTAs. Simply put, call to action describe the one thing you want the target audience to do. Oftentimes, it’s in the form of a big button that appears right in the center of the landing page or at the end of an email.

💡 Tip: Think of a clear CTA.

Sometimes communications happens best outside of our email accounts. To save yourself from sending out another email, try engaging others in async or in-person interactions by leveraging tools like FigJam or one of the tools in this ‘gamestorming’ list.

4. Connection: Build trust with teammates and show concern for their needs, priorities, and preferences.

Many of us know that marketers often invest a ton of time, money, and effort on research and building a brand. One of the main goals of brand marketing is to connect with their target audience in a personal way.

I love the way Amazon Ads describes brand marketing guide describes it:

Brand marketing is the process of establishing and growing a relationship between a brand and consumers. Rather than highlighting an individual product or service, brand marketing promotes the entirety of the brand, using the products and services as proof points that support the brand’s promise.

We, as teammates, also need to build trust with one another in the same way that marketers do with their audiences. This requires time and effort (and probably some money for social and drinks). The better we get to know our teammates, the better we’ll understand their needs and priorities. We’ll know what they would care to know, and what they don’t care to know. We’ll know how they prefer to communicate. We’ll know the best time of day or day of the week to send a chat message. We’ll know whether or not they’re the right person to go to for feedback on an idea.

When it comes to building connections, there are numerous ways to do it. Depending on your team culture, working patterns, and geographies, you’ll find the ways that work best for you. At Coda, we make an effort to build connections through in-person lunches, after-work drinks, virtual cooking sessions, and virtual one-on-one meetups using the Donut app.

Here are three examples of how companies have successfully helped their teams form connections and build trust:

• Arianna Huffington’s Power of Reset practice at Thrive
• Watershed’s Personal Priorities ritual
• Padma Warrior’s weekly Fika sessions at Fable

Closing with a clear CTA.

With all the principles and tips discussed so far, you may be wondering how you and your team can start flexing your remote communication muscles. We’ve discussed the importance of clear CTAs, so I leave you with this:

Next time, before you sit down to draft an email, send a chat message, or craft some talking points for a presentation to your teammates, stop and ask yourself the following four questions about your intended audience:

1. What do they really want to know, need to know, and care to know?
2. How can I simplify my message so it’ll require less time and effort on their part?
3. How can I make it really easy for them to respond to my message?
4. How can I build trust and demonstrate concern for their needs, priorities, and preferences?

4 things remote teams can learn from marketers about effective communication was originally published in Coda Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Coda, we build building blocks — that is, we equip you with the tools you need to create, customize, and solve problems in your docs.

When we first launched Packs in 2018, they were building blocks that integrated third-party apps into Coda. They sent Gmails from your tables at the touch of a button, synced data through Salesforce, and automated messages through Twilio. Centralizing core toolkits into a unified workspace was a huge success, but it was just the tip of the iceberg for what Packs could unlock. And there was a barrier to Pack growth: only Coda could make them.

After seeing all the ways our makers wanted to extend the power of their docs, we set out to empower the Coda community even more. This mission gave us new goals:

• Provide Packs that solve new problems. More than just integrations, Packs can be custom formulas, visuals, tables, and beyond, letting makers find solutions without ever leaving Coda.
• Create a space where anyone — not just seasoned developers — could build a Pack for themselves or their team.
• Allow Pack makers to build a business on Coda by monetizing the innovative solutions they build.

We’re thrilled to announce that the newest updates to the Pack ecosystem get us there. Read on to see how doc makers and Pack makers alike benefit from the new launches in our community-driven tool.

Accessing more Packs brings new ways for endless customization.

No two teams function the same. Coda gives you the flexibility to build a workspace that works for you. We’ve created a doc as powerful as an app, where you can sync all your tools and info, then build custom automations to connect it all.

To further this flexibility, we’ve added a suite of carefully-selected Packs for team and enterprise plans. Expanded access to Packs means more connections to apps, data sources, and custom solutions to your workspace — at no extra charge.

For any Packs outside of your plan, 14-day free trials grant the time and flexibility to test if they’re right for your team and only pay for what your team needs. Here are a few of the Packs available to try:

Most marketplaces restrict this access to paid accounts, but we know that the next great innovation could come from anyone in your organization. We’re inviting anyone on your team to experiment, create, and test solutions without fear — and without ever leaving Coda.

The Packs we’ve included in each plan are curated just for your needs based on their quality, usage, and supporting docs. That also means that as new, community-generated Packs hit the Gallery, ones with noteworthy usage will join these plans.

When you’re able to optimize your workspace, you can focus your time and resources on what’s important: growing your business and increasing productivity.

Turn your innovative solutions into consistent revenue by selling to the Gallery.

A key principle in our decision-making is to empower makers to build businesses in a way that makes sense to them. For the Pack ecosystem, that means granting Pack makers the autonomy to be in charge of your pricing, your content, and your release cycles.

We’ve rounded out the start-to-finish Pack pipeline by opening up the ability for Pack makers to publish and sell subscriptions to their Packs in the Gallery. There, your work can power millions of makers across more than 25,000+ teams, including Fortune 500 companies.

Now anyone can create a custom Pack, release it to the community, make recurring revenue, earn even more through the affiliate program, and track successes along the way with publishing stats. We opted to provide all the resources we use internally to drive successful Packs, so anyone can build, publish, promote, and manage work the same way we do. Here are some of the Packs the community is monetizing today:

Here’s how the ecosystem works:

• The Pack Studio allows anyone to build a Pack through our web-based editor (no downloads or messy setup required!) or through a developer-friendly command line interface (CLI).
• Once a new Pack is ready, makers can publish and sell it in the Gallery. The Gallery contains hundreds of helpful Packs organized by use case so they’re easy for our community find, sort, and subscribe to. Simply publish your Pack through the Pack Studio’s listing section, set your subscription price, and connect to Stripe to collect your earnings.
• The affiliate program pays you for promoting your docs and Packs by giving you credit for referrals and usage. That means you can get a 20% revenue share on any paid sign ups just by posting your own content!
• Publishing statistics allow you to manage, analyze, and optimize the performance of everything you’ve published. This dashboard makes it simple to track what’s working (and what’s not) so that you can create the most lucrative Packs.

Crafting useful Packs elevates the Coda experience for everyone, and you deserve to earn on your innovation. We’ve already seen Pack makers like Scott Weir transform a hobby into their primary source of income.

A community-driven ecosystem lets you shape your software.

Most SaaS companies provide a solution. But we’re letting you take control in shaping Coda, blurring the line between product and community. When growth like this is driven by and for our makers, everyone wins.

There’s no one better suited than our own community to find, understand, and solve problems creatively. More Pack makers means that niche tools, apps, and use cases — like ones listed among our Pack requests — can be addressed quickly and efficiently. And as more Packs enter the marketplace, it ensures the highest-quality solutions for teams to use.

In the short time that Pack Studio has been available, hundreds of new Packs have entered the Gallery. We’ve already seen some serious magic:

• Teams can integrate deeply with Packs like Quickbooks. Pack maker Leandro used insights from other makers in the community to craft this Pack with serious attention to detail — it contains nearly 50 individual building blocks to help teams manage their bookkeeping where they manage their business.
• Customization brings creativity, as you can see in the Mermaid Pack that turns formulas into beautiful flowcharts.
• Anyone can become a Pack maker, including a 7 year old! New Pack makers have joined the community of thousands overnight during the Packathon.

You’ll never outgrow Coda because there are no set bounds for what the tool can be. Access to more Packs raises the bar on what you can accomplish in a doc, and maker-generated Packs bring more opportunities for growth. The keys are yours to build powerful docs and your own building blocks.

Ready to see what you can unlock with Coda?

Get in touch

Power your business with the new Pack ecosystem was originally published in Coda Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Co-authored with Alicia Salvino. Explore this post as a Coda doc here.

Last month, we launched Pack Studio, a way for any user to build extensions and integrations for Coda. Packs add new powers to your doc by supplementing Coda’s core building blocks. And makers from all technical levels have already impressed us with their ingenuity (here’s just one example).

We’re the designer (Alicia) and product manager (Punit) behind Packs, and we wanted to give you a peek into the journey here.

Our vision: The doc that brings it all together for any team.

At Coda, we’re building an all-in-one doc that brings your words, data, and team together. Coda comes with a set of building blocksーlike pages for infinite depth, tables that talk to each other, and buttons that take action inside or outside your docーso anyone can make a doc as powerful as an app. But until recently, only the Coda team could create these building blocks.

With an open Packs platform, we hope to unlock opportunities for anyone to be successful — be it a product team in San Francisco, a real estate agent in Kampala, or a dairy farm manager in Tokyo.

This vision requires three promises:

1. You can build what you need, from robust integrations to custom visualizations and formulas.
2. You don’t have to be a software engineer to build a Pack — but you’ll still love the process if you are.
3. You can build a business making Packs for the world’s most innovative teams, who in turn get amazing solutions at their fingertips (we’ll share more on this in a few weeks).

An API isn’t enough.

One common way many companies try to achieve these goals is through an API that lets anyone connect to their service. We launched an API four years ago and saw teams use Coda docs as databases and makers building DIY template sales systems. But it takes a lot of mastery, time, and effort to get going. While powerful (and we’re still fully supporting our API!), it felt insufficient for our larger vision because:

• Only professional software engineers have the skills to build extensions.
• These extensions can’t be discovered or used directly within a Coda doc.

The result? A limited set of extensions for few teams that feel disconnected from the user experience.

But we realized citizen developers are everywhere. They may have taken an intro programming class or are just now picking up coding on the side. They can code but aren’t experts at it. They’re the people in your company who hack a solution together, your friend who used to build websites as a hobby, or maybe even you.

How might we build a way for professional and citizen developers to create building blocks directly inside the doc? This question shifted how we designed the product from the ground up.

We answered that question with our five product principles:

1. Make simple things simple, and complex things possible.

Early on, we explored simplifying Pack building as much as possible. For example, what if you could build a Pack just like writing text in a special type of doc? We found this meant sacrificing power for ease. It prevented motivated, skilled users from being able to do as much. Setting up important features like authentication or sharing Packs with your team felt confusing and difficult.

Instead, we aimed for simplicity that’s helpful for all — professional and citizen developers.

A better citizen developer experience led to a better professional developer experience. When we decided to allow Pack building in the browser, everyone could get started more quickly, even if they later transitioned to our more advanced tools. When we built good code examples to help those less confident write code from scratch, everyone built Packs faster.

2. Inspire citizen developers in 60 seconds.

Citizen developers can build amazing things. However, our research showed many makers had internalized an identity that they’re “non-technical” or less capable than they actually are. They’ve seen other tools make coding feel complicated, built only for the “hackers” and “l33t” among us. They felt excitement and curiosity for what’s possible — mixed with anxiety, fear, and confusion upon seeing code.

We aimed to show makers their true potential quickly, to motivate them and move beyond this identity. This meant helping them build a working Pack in less than 60 seconds.

Quick affirmation counters the initial headwinds of anxiety. Anything to download? Nope, do it in the browser. Anything to set up or copy and paste? No, just pre-fill examples and set sensible defaults. We made sure to show the maker they can truly build a Pack in just a few clicks. And we found that these emotional assurances benefited even the most advanced developers.

3. Speed up test-and-iterate loops by making every keystroke count.

Building software usually involves doing a lot of things that aren’t just writing code: loading libraries, digging through samples and documentation, managing multiple tabs, understanding the unique nuances/fields of the given API or error, and more. For citizen developers, these issues are particularly painful and intimidating.

Our goal: Make every keystroke a brick in the wall. Omit fluff.

We reduced “figuring things out” time with the / command to give you template code at your fingertips when adding a new building block to the Pack. We automated common tasks such as auto-updating test docs with the latest code. And we made debugging easier with error logs available right inside the doc including support for console.log(), which nearly everyone writing JavaScript knows.

4. Treat code as UI.

Makers will spend significant time writing code, so it’s a primary user interface. We wanted to make Pack code feel familiar yet still powerful for both professional and citizen developers.

We focused on making Pack code readable and simple, with room to expand for more advanced developers. We wanted to maximize the ratio of code that’s unique to the Pack vs. generic to all packs.

JavaScript was an obvious choice — it’s the most common scripting language. Our code examples largely follow common JS patterns over the last 10 years. We designed the code to be modular, making it easy to copy and paste small snippets. We formatted and commented sample code to read as simply as possible.

But JS has evolved over the years. While our examples avoid more “jargony” code patterns, Packs work with these newer, slick syntaxes. And for those who want robust typing, Typescript is optional but enabled.

5. Build the platform with the garage door open.

It’s difficult to know what users will make and what issues they’ll encounter with an open platform.

We immersed every single team member in research from day one and opened our platform to feedback as quickly as possible.

This built empathy, guiding our later choices and motivating fast progress.

We shared the platform with users just months into the project. We launched the Pack Studio private alpha on a Coda test server and invited 30 makers. We saw what problems they used Packs to solve and observed what roadblocks they hit while coding, even observing them code live. We added them to Slack and our whole team supported them: not only engineers, designers, and product managers, but also Codans outside these roles. Seeing simultaneous enthusiasm and struggles motivated rapid, major improvements before launch.

We also leveraged Codan enthusiasm in an internal “Packathon” where all employees built Packs, from sales to recruiting to engineering. Everyone kept a “friction log” of the emotional and functional issues they faced as they built, giving our team deep insight into the full arc of Pack-building.

Start building a Pack today!

As we’ve gradually brought more makers onto the platform, their reactions have been incredible. Coda Packs have become a primary income source for some makers and unlocked new possibilities for teams. This is why we built the platform, and it’s exciting seeing that impact in real-time.

Whether you’ve lived in code for decades, or literally never tried (just like Scott!), we’d love to see the Packs you make. Until August 3, you can join our Packathon by building a Pack for a chance at $20,000 in prizes.

Build a pack in 60 seconds or learn more about the Packathon.

Pack Studio: Five lessons from building a platform with the garage door open was originally published in Coda Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s easier than ever to create digital applications like websites or project trackers, without writing a single line of code.

Those on the ground — who are in the arena — are designing solutions to their community’s problems with some internet sense and a desire to create a better way of doing things. It’s the rise of arts & crafts or a return to vernacular architecture where the new maker generation can use the building blocks of the digital age, all the complexities of servers, protocols, and code humming in the background.

The barrier to creating apps is lowering, and there are an increasing number of tools to choose from. Many tools have gone down the “app builder” route, while a few — like Coda — have bet that the most approachable and flexible surface to create online is something we’ve all been using since the computer came out: the document.

Since there are so many no-code tools to choose from, we developers recommend the following evaluation framework using the four core areas of digital interface, data flows, living development environment, and community.

Interface through the internet.

Many no-code tools allow you to design your content in a compelling visual, accessible to anyone on the world wide web.

Content: How do you create and spread great ideas? The most effective ideas are shared through artifacts like the written word, pictures, video, audio, and diagrams. From the Constitution to the latest TikTok remix, humans have found all sorts of mediums to get their points across. No-code tools allow users to drop whatever they want onto the canvas and arrange it most compellingly for any device. It is commonly referred to as WYSIWYG (What you see is what you get), which differs from having to code the content and then render it later to get the intended result. Coda has canvas, pages, embeds, and layouts for makers to form their thoughts and intentions in any way possible.

Interaction: Beyond static 1-way content, we enter Web 2.0, where there is dynamic interaction between the application and users, probably what you associate with the internet of today. In Coda, you’ll find building blocks like:

• Buttons that take action such as sending emails and adding content.
• Controls where users can adjust settings or dynamically change visuals.
• Reactions such as the social media staple of Solutions Studio, and forms for entering information.

2-way content — information and visuals where users can interact and have conversations and build community with each other — is more engaging and creates more value (user-generated content platforms like Twitter > 1st-party content like a static newspaper).

Data flows.

No-code tools enable you to build apps that give users the ability to create, read, update, and delete data (see CRUD) — from finding the best restaurants in your neighborhood to the progress on the team’s goals.

Databases: No-code tools either integrate with or have built-in databases so that you can structure information. The key is to have an easy-to-use relational database that you can directly interact with. In Coda, you’ll find tables with columns/field types/attributes such as text, number, people, date, and select list so that users know what each is used for and can easily input, edit, and view that information.

The second part is linking tables with each other. In a social media app like Twitter, behind the scenes, there are a bunch of connected tables that hold information, such as a user table with all the user information and a tweet table that associates the tweet with who said it (the user table). Likewise, in business operations, a project may connect to a team, a contact to a company, or a goal to monthly metric updates. In Coda, there are lookups that bring tables together. You can always view any table across a doc — like you’d use SQL to query.

To learn more about this topic: Matt Hudson’s Tables, Not Spreadsheets

Integrations: Most modern apps talk with each other to increase their utility. Have you ever used your Gmail or social media login for a new service? Behind the scenes, even apps like weather.com connect to a data source that the product developers don’t create or own. Apps talk with each other through an API (Application Programming Interface), and no-code tools offer the ability to connect your app with other apps to increase the value of your service.

Coda does this through Packs, bringing instant connection to apps like Gmail, Shopify, Slack, Jira, Strava, Salesforce, and many others. If you’d like to connect to an app but don’t see it, you can create your own with a little bit of code (technically, this is low code) with the SDK (Software Development Kit).

Take actions: No-code tools provide some sort of programming “language” where you can tell the tool what to do for you: query data, automate tasks, calculate, and do things through logic. They come in two flavors, and most tools include both:

• Visual builders: Drag and drop mixed with connectors or form-like experiences guide you in building some sort of structure or chain of commands. Coda’s automations work like this, creating an experience that prompts you to set up triggers and actions: “When something happens, then do this.” For example “When you change the status to Complete message the project team.”
• Formulas: Many no-code makers say that Excel is the most popular no-code tool (even though the company that created Excel doesn’t call it that!). A key part of any application is to calculate, and Coda uses formulas like spreadsheets — such as sum, count, and if — to calculate.

Living development environment.

No-code tools lower the barrier to getting your MVP / Prototype out to your team or generally available in the market. Essentially, the investment and value realization gets closer, the loop between product feature launches and user feedback gets tighter, and innovation cycles spin faster. This is how new products enter the market, and businesses scale during hyper-growth.

Where you build the app influences the time it takes to launch, and for no-code, the application building and launching interface is in the same place, making it simpler to create and easier to collaborate in. For coders, the closest example is the IDE (Integrated Development Environment) which bundles most aspects of development to production workflows.

In a living, breathing document surface like Coda, there is no difference between development and production. It is, at this moment, what it is; it moves forward as you are building. There are no releases to hold you back or buttons you press. If you ever want to go back, there’s version history keeping track of the development.

And because the app exists where the building blocks are (it’s all a doc!), you suddenly bring a collaborative layer into the development surface. Invite collaborators to co-create with you, then invite users by just clicking “share” like any other digital document.

Community.

When investing in a no-code tool, we want a thriving community of makers who are passionate about creating solutions, warmly invite newcomers, and serve each other by openly sharing progress and challenges. This collaborative ethos is seen in the broader no-code community. A good example is #buildinpublic.

• Forum for connecting. Like Stack Overflow for developers, no-code tools create shared spaces to have conversations whether it’s using a tool-moderated platform like Discourse such as community.coda.io, or more casual interactions on Discord, Slack, Reddit, Twitter, or YouTube.
• Open source: The early tech companies like IBM, Xerox, and SAP were closed source. They innovated internally and never shared their proprietary trade secrets. Then came new communities who openly shared what they were building on social code sharing sites like Github — Google and Amazon would build on that stack. Instead of keeping the new versions to themselves, they would share back, creating a flywheel of value and collaboration that spun faster than ever. The same is happening in no-code with folks openly sharing templates, hacks, and solutions. Coda’s Gallery (coda.io/gallery) has great examples of this: John Doerr’s Measure What Matters OKR template leads to Brex’s Quarterly Planning that Doesn’t Suck inspires Pinterest’s Pyramid OKRs, then Robinhood remixes it with the Solutions Studio for their entire company.

In conclusion.

No-code tools are growing like crazy: There have never been so many options for creating your own applications for business, small team, or personally. With the proliferation of these tools, finding the right platform to invest time and money is harder. Determine your needs and how they fit into the four core areas of a no-code tool — interfaces, data, development environment, and community — and you’ll find the right fit.

And, if you’re thinking about Coda, consider partnering with an Architect in the Solutions Studio.

Building web applications without code was originally published in Coda Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Escapades in JavaScript date/time handling.

Date is a common concept — we use date and time every day when talking with each other. However, I realized I knew next to nothing about its technical aspects until I worked on improving support for international dates on Coda. We had a mysterious bug: there were reports from a few users that our Date operations, on some rare occasions, produce Date results that are off by a few minutes. Below is an example where a Coda doc is set to Asia/Kuala_Lumpur timezone and a user finds that a date they entered is off by 9 minutes when referenced in another column.

The same object, but somehow off by 9 minutes.

This is quite bizarre. How could the same value show up differently in another place? I even double-checked that the underlying value was the same. It turned out it was because of a bug with the moment, the date library we’ve been using at Coda.

moment was everyone’s date library of choice, but it has fallen behind and is no longer actively maintained. As we invest in improving support for international users, we wanted to build on a stronger foundation. I kicked off work to replace the library, but little did I know what I would get myself into. Read on to hear about my escapades in javascript date/time handling and what I found the best library to be.

How hard it would be to create a date in a given timezone?

Coda supports various Date formulas. Makers can create dates from components, add and subtract date, and add custom date inputs that should all work in the user-chosen timezone. In order to support makers around the world, we had to find a library that supports a wide set of date time operations for every timezone.

The first test I did was to create a date with different date components (year, month, day) and time components (hour, minute, second) in a specific timezone. It seemed like a simple task until I understood how timezones work. Let’s take a step back to understand the fundamentals of date, time and timezone and why it’s a challenge to handle.

Date, timezone, and offset

If I ask you which date and time it is currently, I’m sure you can answer it without blinking, something like “It’s March 25, 2022, at 3pm.” If I relay the same information to someone on the other side of the Earth, would they agree? No! They would say that it’s March 26, 2022, at 5am. It’s a different time of day and even a different date for them. Although we’re at the same moment in time, the date components are different! To communicate this difference, we usually denote the date with a timezone, and we can convert the date components from one timezone to another based on their timezone offsets. The offset is relative to UTC, a standard time recognized around the world. I’m in California, USA, so my current timezone is PDT (Pacific Daylight Time), and it’s -7h from UTC time. Someone in Vietnam is in Indochina Time, which is +7h from UTC time.

Javascript comes with a standard Date object, but it comes with a severe limitation: no support for custom timezone (it implicitly uses the user’s local timezone). We would have to go through a few hoops in order to create a date a specific timezone with JS Date. Specifically, we have to find out the timezone offset of the date in the desired timezone. And here is why it’s not easy: timezone offset of the same location may change over time. A famous example is when Samoa switched time zones and effectively redrew the International Date Line. There is also a recurring version of this that’s familiar to people in the US and many countries: Daylight Savings Time. Every year, there will be about 5 months where California (America/Los_Angeles) timezone has -8 hours offset, and 7 months where the offset is -7 hours. To make things even more confusing, the day that it happens changes every year!

Fun fact: Standard time zones are introduced fairly recently in the history of humankind! Before 1883, every city in the U.S. had its own time, and the time in each city could vary by a few minutes. It created so much problem with train scheduling that the Railroad companies started using standard time zones and the rest is history.

It’s complex to construct a date in the right timezone, and not every Javascript Date library out there supports it.

How hard would it be to add one day to a date?

Another building block of date manipulation on Coda doc is adding or subtracting from a date. Adding one day to a date is a trivial task for humans to do. One day after March 25, 2022 should be March 26, 2022, and one month after this date would be April 25, 2022, right? What would be so hard about it? Let’s explore this problem through the lens of a computer system.

Unix timestamp

When given a date, the computer doesn’t store 6–7 different numbers representing the different date components. It’s smarter! It stores a single number, a timestamp, representing a specific moment in time. This number represents the number of millisecond from an epoch moment in time (a common one is 1/1/1970 00:00:00 in UTC). Every moment has a unique timestamp, no matter which timezone it is. Based on the timezone offset, this number can be converted to the time at a given timezone and derive the date components.

It’s simple and effective at reducing the complexity of storing time. But not when you want to do some math with it. A naive approach to date math would be adding the number of milliseconds to the timestamp. It quickly fails when you realize that:

• A year doesn’t always have 365 days
• A month doesn’t always have 30 days
• And a day doesn’t necessarily have 24 hours.

Wait, what? A day doesn’t always have 24 hours? That’s right. Remember that DST may change a timezone offset forward or backward by 1 hour? Let’s look at California DST changes this year:

On March 13, 2022, the Pacific Time (PT) timezone switches from being -8 hours from UTC to -7 hours from UTC. This day loses 1 hour because after 01:00 AM, it will be 03:00 AM! Worry not, on the DST end day, November 6, 2022, the day will have 25 hours to make up for the loss! To everyone who wishes for 25 hours a day: your wish is granted 1 day a year. Cheers!

To everyone who wishes for 25 hours a day: your wish is granted one day a year!

A better way to approach date math is differentiating calendar math and time math. When adding days, months, years, we should add directly to that component instead of adding milliseconds. With that, we circle right back to the first problem, which is creating a date from specific components.

Let’s take a moment to appreciate the challenges of handling timezones:

What is the best date library for timezone handling?

It took me awhile to understand the challenge at hand and, frankly, I don’t want to be dealing with this madness. Thankfully, there are kind souls out there who has solved these challenges and made their code open sourced. I looked at popular open-sourced date libraries out there and tested how they faced against the tasks of handling timezones.

luxon was the clear winner! Join me in celebrating the existence of luxon! If you don’t have to deal with complex timezone logic, that’s fantastic; the other libraries may work for you. But if you do, you know which library to go to. Before I understood the complexity of handling timezone logic, I tried to compare the libraries based on fancy features like tree shaking, bundle size and so on. But now, I’m content that there is even something that handles all the messiness of timezone as well as luxon. In fact, I learned a lot about timezone math from luxon‘s fantastic documentation.

Moment strikes back!

We found the ideal replacement for moment, and it was luxon. It was time to migrate our data and codebase off the old library to the new one.

Now I can explain to you what caused the bug we saw at the beginning of the post. moment‘s approach is to bundle the timezone offset data with their library (in a different bundle called moment-timezone). However, it doesn’t and is not practical to bundle all the available timezone offset data. This creates a difference with modern Javascript Date formatting API supported by most browsers nowadays, Intl, which has a complete offset data bundled with it. Since Coda used Intl API to format a date, the same timestamp in moment is presented as a different time in Intl, hence the bug we observed. We don’t have this problem with luxon because they use Intl API under-the-hood for timezone offset data.

This brings up a migration challenge: if we simply swap out moment with luxon, many of our dates would stay wrong. We have to rewrite the timestamp that was handled wrongly by recomputing the timestamp with luxon. In general, if you migrate from moment to any recent date libraries, you may have to do this too, because they all use Intl API under-the-hood now.

Now, this “timezone offset change” actually can happen in reality without changing the date library. In fact, the US Congress is considering making DST time permanent in the U.S. If a date is converted to timestamp, stored in a database and stashed away for two years, it might be read as a different date when the change is in-effect. Storing timestamp is not a silver bullet. Ideally, we should store a pair of timestamp and timezone offset to uniquely capture a moment in time at the time it’s created.

One more thing: date unit tests

One of the challenges I faced when migrating our code was date-related unit tests. There are unit tests for our date formulas and date utility functions. Since they are tested against multiple timezones, the result is usually timezone-dependent, and it’s a challenge to write the expected result. We ended up with various ways of writing imprecise expected results. Here are a few examples:

They are imprecise because depending on the offset data used (moment API, Intl API, JS Date API), the timezone offset for a given Date & timezone may be different, and the resulting date string may be different. They become a challenge when removing moment because there are a lot of confounding factors that relate to a test failing, such as a bug, converting function, or data specific to moment.

How might we achieve both simplicity of writing a unit test and the precision of the test? I spent a lot of time pondering this question, and this is where the fundamentals we learned above become useful: we need precise date components and timezone offset for the expected date. Here is a desired, standardized API that I created that offers a simple and easy-to-use API that fellow developers can use without having to think about timestamp and offset.

Behind the scenes, the expected date string & timezone are mapped to a validated timezone offset, based on sources like TimeAndDate website, producing an exact expected date. When a test fails, we would print out the differing component, making it simple to spot the difference between the actual date and the expected date. We can unify the way dates are tested in our code:

Example of unit test changes.

Takeaways

The project has been a journey through the twists and turns of time! I’ve learned more about date, timezone, and offset than I ever wanted, but I can be the go-to person in the team for date-related matters now. The learning also made it a rewarding journey! Coda now has made away with bizarre Date bugs and has a better foundation to build more date time support for our users.

Here are a few useful takeaways:

• If you are serious about timezone support on your website or platform, pick luxon and never turn back!
• Use a pair of timestamp and timezone offset to uniquely represent a moment in time. Timestamp alone is not enough, and timezones don’t have a fixed offset.
• Lastly: Date & Time handling is complex, avoid it if you can!

I was naive about the complexity of this problem when I jumped in, but hopefully, by sharing the knowledge here you’ll come to the problem more prepared than I am!

And if you are interested in deeply challenging technical problems like this, come join us; the Coda team is hiring!

Bringing Coda up to Date: 25-hours days and other things I learned when migrating from moment date… was originally published in Coda Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Whether you’re a student, teacher, or a startup that’s just getting off the ground, we know you face challenges like limited time, resources, or budget. You need to be choosy about the tools that help you get things done, which is why we’re expanding our savings and programs so you can get the most out of Coda.

We’ve already seen thousands of startups and education makers use our discount offerings to do more with Coda, for things like taking class notes, creating a full-blown business, and everything in between.

Now, it’s more affordable than ever to try out Coda for yourself and your team.

Quick starts for startups

Disrupting is hard. Choosing the right tool for your startup shouldn’t have to be. We know that startups need to be fast and nimble, and the tools to make that happen should be just as quick and flexible.

After piloting our Coda for Startups discount program and scaling to thousands of companies, we saw startups use Coda when getting off the ground, scaling their processes, and keeping up with growth. Pangea, a job network for college freelancers, first turned to Coda to organize each team’s goals in one place, and they liked that Coda could connect to the tools they were already using. They’ve since expanded to bring a bit of joy into their workday, like a midday trivia doc and a Monday motivation doc to start the week on the right foot.

With this kind of early success, we’re excited to launch updates to our startup offering.

To help startups hit the ground running with Coda, eligible companies can receive $1000 credit for their workspace, applicable to our Pro or Team plans. While it is dependent on which plan you select and your team size, on average this discount lasts startups more than 1.2 years.

Here are some other ways we support startups using Coda:

• Join the Discord community to learn from and network with other startups using Coda
• Explore templates tailor-made for startups looking to build their day-to-day operations, like setting goals, planning product launches, or managing costs.

Apply for a $1,000 credit for your startup. Learn more.

Pro access for students and educators

Whether you’re a student who needs to keep personal projects organized or you need to stay on the same page with others, the Coda discount can help supercharge your productivity. Makers have already put these plans to good use. For example, Babson College junior Jason Sol built an interactive hub for university clubs on Coda. And Lafayette College freshman Angela Busheska wants to track side projects in Github to stay motivated and ultimately land a software engineering internship. She turned to our Github pack to get granular analytics about her Github repositories and published her doc so other students can stay motivated with progress trackers and visualizations.

For students, teachers, and education professionals, you can access Coda’s Pro plan with one Doc Maker for free for as long as you are in school or working as a teacher. For those who need a plan with more than one Doc Maker, we offer 80% off of Pro or Team workspaces. (Note that this 80% discount does not apply to an entire school or university. For broader access and discounts, please reach out to our sales team).

Apply for one of our many discounts for students, teachers, and administrators. Learn more.

If you have any questions about our discount programs, we’d love to hear from you! Please reach out to support@coda.io.

Expanding what’s possible for startups and students was originally published in Coda Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.