Scaling your organization with OKRs (and RedwoodJS)

Show & Tell
#1

Hey everyone :wave:,

Over the past year, I’ve been working on an application to solve two problems that I’ve faced in the past:

  • I’ve wanted to know the measurable impact that my team has had on a business.
  • I’ve wanted transparency in how objectives across an organization tied into larger business goals.

There were several apps that each solved a portion of this problem, but none that solved it in a holistic way. So I decided to build Commonality.

I started building the application using Prisma’s Nexus framework with a React SPA but keeping things in sync became a pain. I tried Next.js with some Prisma layered in, but the ergonomics didn’t feel optimized for complex SPAs. I even tried AWS Amplify, but the datastore library wasn’t as mature as Prisma’s client and couldn’t handle complex use cases within GraphQL resolvers. Then I tried RedwoodJS, and everything just fell into place. It was a wrapper around all the tools I had tried to stitch together manually and felt like it was built to handle applications that scaled.

I’m using RedwoodJS in production with dozens of components and cells, and utilizing tools like Cypress and Quirrel (shoutout for making a RedwoodJS specific package).

I’m happy to answer any questions that folks have about working with a large RedwoodJS codebase or experiences building certain use cases. I just launched Commonality today :rocket: so any feedback, bug reports, etc would be much appreciated as well!

Take Commonality for a spin

meta
meta2400×1254 217 KB

8 Likes
#2

Awesome! Eager to be able to work with it.

Did you work alone on this? How long did it take you?

Welcome in the community btw :stuck_out_tongue:

#3

Hey @alecortega

This is a really nice app! I don’t have any experience with OKRs, but I’m very interested.

Like you, I tried many similar stacks before RedwoodJS, and I think we can agree that for this type of project, RedwoodJs is the best framework we can dream of. :wink:

Also, I believe new users would like to have an organization example like Vista Venture to quickly see the benefits of Commonality.

Thank you for showing your app; good job!

1 Like
#4

I worked alone on this for about 6-8 months in my free time. It’s been a side-project for a while but will definitely be working on this more now that folks are actually using it.

Also, thanks I’m happy to be here! :smiley:

5 Likes
#5

Thanks for the praise! Commonality definitely has some more growing to do, especially on the user activation front. That’s a great idea.

2 Likes
#6

This is awesome! It is honestly a really polished app and you have managed to handle the UX really well (such as loading indicators on Cells, and avoiding any white flashes).

Where are you hosting this at the moment? I did not notice any cold boot API slowness.

I am also curious to hear what best practices you have applied to redwood either on the API side or web side, to be ready for production and real users. Or if there is some patterns you can share for us getting towards launch with our own apps!

1 Like
#7

Hello, @alecortega welcome and congrats on the very slick app. I am interested in your background experience that allowed you to cover such algorithmically complex issue like OKR

#8

The app is hosted on Vercel right now. I’m also using https://betteruptime.com to run a few monitors against the functions and UI, which might be helping with the cold start time.

My biggest advice would be to embrace a super flat file structure and the Storybook-first method of building components. When I started using Redwood, I fell into the habit of breaking up growing components into separate files within the same component/cell folder. As I kept building, those sub-components grew as well, and I lost the Storybook and testing benefits that Redwood provides out of the box. Now, every time I feel the need to break out a new component, I always use the CLI’s generator and follow a one component per component/cell folder rule.

2 Likes
#9

I’m glad you like it!

I’ve worked on several engineering teams focused on business growth in the past at companies like HubSpot and ezCater. On all those teams, we used the OKR model to measure our team’s impact on the bottom line of the business. A lot of the data we were using to measure progress for results was siloed in tools like Looker or Tableau. Even though we had direction, there wasn’t a lot of visibility into how our team affected other teams above us. I built Commonality to solve that problem.

I get excited when I’m able to say, “We built X feature which increased conversions by Y% which increased MRR by $Z.” I wanted to build something that empowers every employee, no matter what their level or department, to have that same experience.

2 Likes
#10

Oh neat trick with uptime monitoring! Will give that a try. How do you test your UI at the moment with uptime monitoring tools?

I must say, I don’t use storybook and in fact have gone through your exact growing pain and put in multiple exports into one component haha… I honestly thought using storybook would slow me down because I would need to think ahead quite a bit. Will revisit and give it another chance.

So what does your workflow look like when you are making a new page, that has some new components or a cell being added? When does storybook come into it?

Oh one additional question - what error tracking and logging service you are using in production?

2 Likes
#11

Congrats @alecortega, this looks really sleek! Looks like this site is using tailwind?
Would be cool if you created some kind of video/course or tutorial on how you approach this. How you’re thinking, planning and actually coding it, while using RedwoodJS. I think a lot of newbies (like my self) get passed the amazing tutorial from Rob, but we want to get to the next level, which is understanding most problems and use cases, and then how to break that down into smaller pieces so that we can follow along, and if the example is generic enough, it could probably be used for 1000s of use cases. THIS to me would make the world of difference. Anyway, thank you so much for sharing, would be cool to connect (up for some mentoring?, I need one) to learn more.

All the best,
Stian

2 Likes
#12

I support this idea wholeheartedly and have an actual proposal for organizing such a task:

@alecortega most likely does not have the time to create such a tutorial with high quality and sufficient focus on all details (understanding most problems and use cases, and then how to break that down into smaller pieces so that we can follow along, and if the example is generic enough, it could probably be used for 1000s of use cases). However, he might be willing to supervise/advise a team of novices (Stian and I could be the forming members) interested in taking the class “Redwood application development”.

In order to make it well organized and structural, the RAD (“Redwood application development”) task might be implemented as a Lerna repo in redwoodjs · GitHub organization and be subject to the same rules that are applied to the the RedwoodJS core team. Naturally RAD team could also be feed with core team’s overflow, documentation tasks (I have a whole slew of ideas how to make RedwoodJS documentation on the level with RedwoodJS code.

Let’s see what @thedavid thinks about this idea, before I get too excited.

1 Like