
Ask HN: Best internal tools your startup built? - tramGG
I&#x27;m interested to hear what internal tools you&#x27;ve built at your startup and why it was successful!
======
jordan_
[https://github.com/jwdeitch/pg_migrate](https://github.com/jwdeitch/pg_migrate)

Postgres migration tool; super simple and lightweight :)

------
hawksy
I ran a grocery ecom marketplace earlier. Getting catalogue up and running
from each store used to take pretty long time, POS wont have images but just
barcodes and short names.

So we developed this tool called Stockpile. It had 1) Admin app - web 2)
Mobile data collection app

Every day the server identifies products that do not have images, and from
which store.

The on field data collector goes to the corresponding store. The app will
display bar codes and short names.

He goes ahead and scans the bar code and takes image.

Over time we also added intelligence in the office admin app to fuzzy match
product names and reduce the effort of offline data collection.

Using this, we could onboard a store and make them online with 12000 SKUs
within 4 hours.

------
osrec
We built our own accounting/invoicing/expenses/time tracking and projects
tool. As it became more robust we started offering it as a service to our
consulting clients. Feedback was positive, so eventually, we wrapped it into a
fully fledged SaaS product (link in profile if anyone wants to check it out).

------
david90
We built our own server for apps in Go- turns out open sourcing it
([https://github.com/skygeario/skygear-
server](https://github.com/skygeario/skygear-server)) . Not really popular
yet, but we used it for nearly all our internal projects.

------
geophile
In 2003 I started working on a distributed file store for archival, (an
"object store"). I was responsible for the metadata management component,
which was implemented by a Java distribution layer over a postgres database on
each node.

I needed to operate on all nodes of the cluster. cssh opens a console on each
node, and echoes commands to each. But that doesn't scale well past about 12
nodes, doesn't combine results from nodes, it really didn't work for me.

I wrote a tool I called Object Shell, or osh. The idea is to combine commands
by passing data over pipe-like connectors. Osh is written in Python, and the
commands are customized by Python functions. E.g., to find all the files
recursively inside the current directory, and add up all the sizes:

    
    
        osh ls -rf ^ f 'file: file.size' ^ red + $
    

osh: Invokes the tool

ls -rf: List files (f) recursively (r), yielding a stream of Python file
objects.

^: Pipe the stream to the next command.

f: Apply a function to each item in the input stream, writing function output
to the output stream.

'file: file.size': A function that returns the size of a file.

red +: Reduction using +, combining all the numbers coming in.

$: Print result to stdout.

And then to do this for all files under /foo/bar, in all nodes of a cluster
named mycluster, and to do a cluster-wide sum:

    
    
        osh @mycluster [ ls -rf ^ f 'file: file.size' ^ red + ] ^ f 'host, sum: sum' ^ red + $
    

@mycluster [ ... ]: Distribute the bracketed code to each node of mycluster.

f 'host, sum: sum': The distributed command returns results that include the
host name; drop the host name.

red +: Sum the sums from each node.

Osh is available here:
[https://github.com/geophile/osh](https://github.com/geophile/osh)

~~~
reacharavindh
How is it different from using pssh and pass "du -sh /foo/bar" farmed out to
all nodes?

~~~
geophile
Because in a 100-node cluster, you get 100 du results. With osh you can post-
process cluster output in arbitrary ways, e.g. summing.

Also:

\- Piping of Python objects instead of strings.

\- Integrated database access (SQL results -> stream of Python tuples).

\- Support for arbitrary Python processing.

------
laander
A few different tech projects that we consider open sourcing:

\- A CLI release tool that properly ensures deps & CI are green, bumps
version, creates Github release notes (with links to PRs) and notifies team.
Is configurable to be used across projects (both backend and frontend).

\- A deployment dashboard that shows what version or feature branch is
deployed for each of our projects on our different envs (prod, staging,
testing etc). Think a minimal matrix grid for easy overview.

\- Elaborate bash script that helps setup all projects and dependencies local
on new employees' machines. Onboarding was always a major hassle so we've
tried to automate it as much as possible.

------
muzani
We ran an e-commerce mobile app. There were no real tools for this; things
like Shopify were designed for web.

So we built a whole shopping cart and inventory management system from
scratch. It was good enough that people were willing to pay for it. But we
were only 98% confident in it so we kept it internal.

We also didn't have the funds to develop or keep testing it. If we shut down
the company, I might open source it.

~~~
corobo
> It was good enough that people were willing to pay for it

> We also didn't have the funds to develop or keep testing it

I have to wonder, why did these not cancel each other out?

~~~
muzani
It takes a while to go from 98% confident to 99.9%. And a lot of refactoring.
Internal tools can be really sloppy, especially when we were selling like 3
items a day.

Something that's paid for and trusted to manage several million dollars worth
of inventory has to be a lot more robust.

Investors didn't like the idea. I guess we didn't sell it well as one of them
invested in someone else doing the same thing but with less experience.

------
dpeck
some of the code with highest return on investment that I've ever written were
simple tmuxinator "dashboards" that were just wrappers around standard tools
(curl/watch/figlet/etc).

Never discount the effect that dusting off some old CLI skills can have. Fast
turnaround, easy to run on osx these days, and the kids think you're some kind
of wizard.

------
habibalamin
A tool to clean up `docker ps` output for our internal QA containers.

------
longnguyen
We built a heroku clone (sort of) based on Kubernetes, helm.sh and firebase.

~~~
mirague
Did you create something along the likes of deis.com?

~~~
longnguyen
Yes. We decided not to use deis workflow because for some reasons, deis made
our infrastructure unstable.

~~~
aalhour
Are you going to open-source it? My company was looking at Deis but then
Microsoft killed the workflow project when they acquired it.

~~~
longnguyen
It's always on our radar but at the moment I don't think it's ready yet.

