[HN Gopher] Serving 250k Developers with One Support Engineer
       ___________________________________________________________________
        
       Serving 250k Developers with One Support Engineer
        
       Author : dban
       Score  : 60 points
       Date   : 2023-02-24 20:22 UTC (2 hours ago)
        
 (HTM) web link (blog.railway.app)
 (TXT) w3m dump (blog.railway.app)
        
       | fuddle wrote:
       | I was impressed by their pricing, how do they keep costs so low?
        
         | paxys wrote:
         | I have spent the last 10 minutes on their site and am unable to
         | figure out what the pricing even is.
         | 
         | Going by the top of their pricing page
         | (https://railway.app/pricing): $10/GB per month RAM & $20/vCPU
         | per month is actually pretty expensive when compared to stuff
         | like fly.io and even EC2/Azure.
         | 
         | Apart from that, what vCPUs are these exactly? What are the
         | bandwidth costs? Custom domains? Certificates? Load balancing?
         | Disks? Databases?
         | 
         | Clicking "Choose Plan" takes you to a login page, but then if
         | you log in the pricing page disappears altogether.
        
       | revskill wrote:
       | With bad documentation on buildpack, it's hard for me to go on
       | with Railway. (For example, there's no sample or docs at all for
       | how to build image with multiple buildpacks like in heroku).
       | 
       | And these days, good documentation is 1st criteria to trust a
       | platform / framework / library.
        
         | justjake wrote:
         | Railway team member here:
         | 
         | So there is one but, if you can't find it, it's as good as
         | there not being one!
         | 
         | It's currently located at
         | https://nixpacks.com/docs/guides/configuring-builds#change-w...
         | 
         | Is there some place you'd expect it to be instead? All ears on
         | feedback!
        
       | swatcoder wrote:
       | Congratulations on achieving this milestone and probably keeping
       | your customers very satisfied along the way, but I eagerly look
       | forward to the future where everyone is so sick of virtual
       | assistants, bots, and knowledge bases that a _low_ ratio is what
       | gets celebrated as a growth milestone rather than a high ratio.
       | 
       | Automated triage is great for digital companies that want to
       | scale cheaply, but not so great for the people who need to figure
       | out how to usefully navigate them, with the brick wall support
       | experience of Google/Facebook/etc being the already vivid
       | example. It helped those companies grow and court techno-optimist
       | investors, but nobody outside of their enterprise customers is
       | _happy_ about the customer service experience. Eventually, that
       | becomes dirt on their reputation and works against their
       | continued growth and success.
        
         | ndneighbor wrote:
         | Honestly, you hit the nail on the head on what drives me.
         | Before this I was a PM, and way even before that- I was an
         | Infra Engineer. I think that brick-wall of contact when working
         | on some Enterprise tool was what got me. ESPECIALLY so when
         | there was a bug blocking my company and it felt like no one
         | cared.
         | 
         | When I first joined- this is why I would take great pains to
         | respond to everyone extremely quickly. When I realized that was
         | not sustainable, the focus then shifted to really making sure
         | that our users are heard and their concerns are acted upon.
         | Sure first contact SLA of 30 mins is great but- doesn't mean
         | shit if we don't solve your problem.
         | 
         | So I think yes, tooling should be first. I think there is just
         | a way for that tooling to serve the developer, not some OKR.
        
       | nbrempel wrote:
       | Very impressive!
       | 
       | That growth curve is amazing.
        
       | trynewideas wrote:
       | > As a team of one, we were able to support 250k users, and now
       | that we've crossed that bridge, our goal is to support two
       | million users with our 2-person team for a 1M-to-1 ratio.
       | 
       | Is it weird then that they have an open req for a support
       | engineer: https://railway.app/careers/support-engineer
        
         | ndneighbor wrote:
         | heyo Angelo (author) here-
         | 
         | This is actually the original blogpost that we used to make our
         | first hire!
         | 
         | > You will be working with our existing Support Engineer,
         | Angelo - to build out processes, formalize policies, and build
         | out integrations between systems to make it so that we can
         | track and record issues.
         | 
         | I accidentally left that one open... but the Ashby interface is
         | so confusing I don't know where to toggle the visibility. I
         | will remove that and then wait for our jobs page to rebuild.
        
           | lotsofpulp wrote:
           | FYI, not disclosing at least minimum pay means applicants
           | should assume pay will be below average. Also, it says
           | "remote - anywhere" at the top, and if you are hiring remote
           | in California, Colorado, New York City, or Washington state,
           | employers are legally required to advertise pay range on job
           | listings and possibly other compensation details.
           | 
           | > At Railway, we provide best in class benefits. Great
           | salary, full health benefits including dependents, strong
           | equity grants, equipment stipend, and much more. For more
           | details, check back on the main careers page.
        
       | fishtoaster wrote:
       | Seems like good tips for any support org trying to keep a handle
       | on load:
       | 
       | 1. Get a support tool (or in this case, roll your own, then buy
       | one when you outgrow that)
       | 
       | 2. Build/buy tooling to direct users to existing documentation
       | that might answer their questions
       | 
       | 3. Move any routine tasks that require a human to automated self-
       | serve tools.
       | 
       | 4. Rope your community into answering eachother's questions.
        
       | swyx wrote:
       | extremely impressive, love the chart showing the major
       | developments. congrats Railway!
       | 
       | (disclosure: am small angel)
        
       | mkl95 wrote:
       | Any SLAs worth mentioning? Did you ever struggle with them?
        
         | ndneighbor wrote:
         | One thing that didn't make it into the article (I ramble and
         | rant) is how I set it so at one point that Teams were entitled
         | to a reply from me or the founder 24/7. This broke nearly
         | instantly after 50 Teams.
         | 
         | At the moment we don't but I spoke to the fmr. Head of Support
         | at Stripe and he told me we should think about our product
         | coverage like an API, some parts of the product (builds for
         | example) should be more critical on response times than others.
         | My main goal this year is to publish an SLA table so that we
         | can work with ever larger customers setting the right
         | expectation.
        
       ___________________________________________________________________
       (page generated 2023-02-24 23:00 UTC)