• she/they

38, irish-american
גִיוֹרֶת

Header from here

posts from @possumskull tagged #cohost

also: #Boyrap Premium

staff
@staff

Happy tuesday, coposters! We’ve just had our End Of Month Meeting, which means our financials are fully up to date, which means it’s time for another financial update!

Since last month’s update included background and definitions, I’m going to forgo re-defining terms we’ve already used. I highly recommend going back and reading that if you’re confused about anything or want additional context. Let’s get started!

Activated vs. Active users

As you may know, a couple weeks ago we changed how we’re calculating a True User Count, moving from a number that reflects “users that are allowed to post” to one that reflects “users that actively use the website.” In our case, “using the website” means that in the last 30 days you have either (1) liked a post, (2) shared a post, (3) made a new post, (4) or commented on a post. The inclusion of liked posts and shares means that unactivated users can be counted as part of this number.

Another distinction to make is between “Users” and “Pages.” Within the codebase, “User” is little more than a shell for an email and password, a cohost Plus! subscription, and some display settings. Almost every single action you take on the website (including all the ones we count for metrics) are done as a “Page.” For example, I (jae) am a user. When my account was created, a Page (@jkap) was created alongside it.

There is not a 1:1 mapping between users and pages. Every user has at least one page, but as you know, creating new pages is easy. Since we are only able to track usage by pages, it doesn’t completely reflect how many individual users are active, but it’s close enough for our purposes.

As of right now, we have 19,056 total users, of whom 17,310 are activated. These users account for 19,105 activated pages, of which 4,314 are active. Our active page count has been growing since we actually started tracking it (and as a result started activating more users) and we’re expecting further growth there. We keep activating users at a rate of 999 per day. Once the current queue is cleared, we’ll share an update on how we plan to handle invites moving forward.

Conversion rate and subscriptions

We’ve moved to tracking conversion rate to be based off of Active Pages, rather than Activated Users. Active Pages give us a more realistic picture of how many people who cost money are using the website.

As of August 28, 2022, we have 476 cohost Plus! subscribers, accounting for $2,223.56 of MRR. This is up from 358 subscriptions and $1,692.36 MRR as of August 3, giving us an average of 4.72 new subscriptions per day. This is up from our previous rough average of 3 per day, and we’re happy with that growth.

Our current conversion rate for Active Pages is 11.39%. Since we’re well above our target levels for conversion rate, we’re okay with this going down if that’s a product of the site growing and becoming more active.

Overall profit/loss

MRR growth means we’re looking better for the end of the quarter and year, even with increased hosting expenses and the addition of a new contractor to assist with development work.

As of today, we have a total of $158,711 in the bank. We still intend to raise additional funding before the end of the year. So far, in Q3, we have lost only $43,417, which is incredible and puts us on pace for only losing around $70k this quarter. For reference, our Worst Case estimates put us at losing a bit over $79k.

For a slightly more detailed breakdown, so far this quarter we’ve spent $56,653 and earned $13,326. Of these expenses, around $44k is payroll, $5,200 on hosting, $5k taxes, and $1,300 for our lawyer and accountant. Our monthly hosting expenses are actually getting smaller right now, through various improvements to the site — recently, Colin’s improvements to performance, and fixing some issues with our internal logging and metrics — allowing us to consume fewer resources while still keeping the site running. That said, we won’t really start seeing the impact of this until next month.

Our contract with Jess is for $50 per hour (our standard rate, calculated based on our employee salaries to be roughly equal, plus a little extra to compensate for no benefits and contractors having to remit more payroll tax), maximum 24 hours per week, for 12 weeks. The maximum cost of this contract is $14,400. Jess starts on September 7, so her contract will be split across Q3 and Q4, with roughly 1/3 of it occurring this quarter. This is included in the estimated loss for Q3 listed above.

With MRR where it currently is and our worst case expenses, we expect to end Q3 with at least $128k in the bank, and end Q4 with at least $39k.

These end-of-year estimates keep growing, which is incredible news for us. That year-end estimate of $39k is up $15k since last month, and gives us an extra half-quarter of runway going into 2023, although as stated before, we will be raising additional money before the end of the year.

Looking forward

On the Revenue Product front, we are still planning to launch gift subscriptions for cohost Plus!, user tipping, and creator subscriptions. We do not have timelines that we’re ready to share for any of these features.

On the non-revenue front, we are also still looking to improve the experience when the same post is repeated multiple times on your feed, as well as improvements to notifications, adult content, and CW’d posts. We’re also still planning to ship posting features like inline images (without markdown or HTML), audio uploads, and additional post types like Asks. We don’t have timelines we’re ready to share for these features either, but they remain on the roadmap.

We are currently planning a move away from Cloudflare as a provider of various networking services. When we chose them a few years ago, we had ethical reservations given some of their other customers, but at the time they were the only provider with a few features we needed. This is no longer the case, and the ethical concerns have only grown since then. We will post updates about the migration once we know more details.

That’s all for now! Thanks for tolerating nearly 1200 words of Business Talk. This sort of transparency remains important to us and we intend to keep it up moving forward, even if it’s a bit dry to read. Thanks, as always, for using cohost! :host-love:

~jae


@possumskull shared with:


ltsquigs
@ltsquigs

Everyone is messing with CSS right now, but there are also plenty of just regular HTML tags that cohost lets you put into the posts. I figured I would make a reference of what those tags were and what they look like for anyone wanting to do something Markdown doesnt quite do.

Basic HTML Formatting Tags
A non-exhaustive list of basic HTML tags that work
TagWhat it do?How It Renders On CohostDocs
<a>Link to a URL.GoogleMDN
<abbr>Marks that a word is an abbreviation.CSSMDN
<b>Emboldens text.Example TextMDN
<blockquote>Indicates that the contained text is an extended quote.
Example Text that should span multiple lines
MDN
<br>Forces a new line.First Line
Second Line
MDN
<bdo>Overrides the browser default direction for rendering text.This text will go right to left.MDN
<code>Indicates that the text included is programming code.var example_code = 'test';MDN
<dl>, <dt>, <dd>Used to create a list that includes definitions of each item..
Item 1
Definition 1.
Item 2
Definiton 2.
MDN
<figure>, <figcaption>Used to display a figure (such as an image) and give it a caption.
eggbug
eggbug
MDN
<hr>Creates a horizontal seperator across the container.First Line
Second Line
MDN
<i>Marks text as italic.Example TextMDN
<ins>, <del>Marks text as having been inserted or deleted from a change.Inserted TextDeleted TextMDN
<img>Includes an image. (Note default style has lots of margin, can override with style)eggbugMDN
<mark>Marks the text as being markedMarked TextMDN
<p>Indicates the text is a paragraph.

Paragraph 1

Paragraph 2

MDN
<pre>Displays the text inside without collapsing any whitespace.
First Line
Second Line
MDN
<q>Marks the text as being an inline quote and adds appropriate quotation marks.Quoted TextMDN
<ruby>, <rp>, <rt>Used to indicate text includes ruby characters (e.g. furigana).MDN
<samp>Marks the text as coming from sample computer outputExample TextMDN
<sub>Marks the text as being subscriptExample TextMDN
<sup>Marks the text as being superscriptExample TextMDN
<s>Strikes through the textExample TextMDN
<small>Makes the text smallExample TextMDN
<summary>, <details>Used to show a summary and give option to user to expand into details
Example Example Text
MDN
<table> (et al)Used to create tables.This whole thing is a tableMDN
<ul>, <ol>, <li>Used to creatae order and unordered lists.
  • Unordered List
  • Unordered List 2
  1. Ordered List
  2. Ordered List 2
MDN
Obscure/Redundant HTML Formatting Tags
HTML Tags that are obscure or redundant
TagWhat it do?How It Renders On CohostDocs
<cite>Indicates that the text included is a citation.Example CitationMDN
<dfn>Indicates a term that is being defined.ExampleMDN
<em>Emphasis text.Example TextMDN
<kbd>Marks text as being related to keyboard keysCtrl + Alt + DelMDN
<strong>Marks text as strong.Example TextMDN
<time>Marks text as representing a time.MDN
<wbr>Tells the browser it can force a wordbreak at a point.ExtremelylongonewordtextthatshouldbebrokenMDN
<var>Tells the browser the text is a mathematical variable.xMDN
Containers: <div>, <span> There are two tags primarily used to encapsulate and organize other HTML tags, DIV and SPAN.

If you want to know the technical details of the difference between the two... google it.

The short of it is that DIV is a "block" container, it is meant to represent an independent block of content. Most browsers will render a DIV as wide as the space it is contained in, effectively making any elements after a DIV element render in the next "line".

SPAN on the otherhand is an "inline" element and is meant to contain only elements that can be rendered inside of other contnet like a text block. It does not take up the whole space it is rendered in but also has no inherit width.

Of course everything I just said up there is only true most of the time, and historically everyone has ignored the rules on how you are supposed to use DIV and SPANs and browsers have created whole sets of exceptions and rules to how they work.

If you really really need precise container control, go google Flexbox.