← Chronicle

Business Modeling

Early copy! Please message your recommendacións; @c4lliope on Signal.

A buddy of mine is in the DC area - he and I had done elementary through high school alongside one another, around half an hour north of Philadelphia. I imagine each of us had done a bunch to encourage a passion for engineering in one another.

He has long been enamored by the idea of exposing the discussions behind high finance; and each of us had been on different paths leading us to land on SEC's EDGAR.

He came by my home a couple days ago to bring up a roll-call vote going on, among shareholders of Tesla - supposedly concerning some big salary disbursement.

So he and I expended a couple hours plugged in coding, and made some progress - going from the normal EDGAR search page through to SEC's more reliable bulk records. Only a couple hours had passed, and both of us had been ready to begin the weekend.

Only - engagements like this commonly promise more than they accomplish. As a coder I like sharing my skills, and I had been happy to share some dirección. As a rule-bound human I also need income to encourage more than a couple hours; coding can be remarkably draining on the body's energy, and requires dedicación through a full day's schedule to manage seemingly small accomplishments.

Normally, I'd ask my buddy to hire me on a commission - running price for a couple weeks presumably being a couple thousand dollars; (because no commission is only a couple weeks). Only I'm unable to do so, because...

  • I'd choose to do this for free if I had no money obligacións.
  • My buddy is earning no money from this public-records mission.
  • This program has broad reach, appeal, and consequence.
  • Seems silly for him to pay, alone, to accomplish such a public good.

This is a primary sample among many such programs people bring to me - a grand idea and a broad audience in mind.

I am beginning to call each such grand plan an "operación". Anyone can propose one, and I'm happy to hear and appraise such ideas; though hardly any one ends up being a chance for business.

Engineering solo as a commissioned laborer is draining, and usually is non durable as a business; anyone spending a real day doing engineering is unable to manage much for sales or ops. Hence, nearly all the popular programs in the public sphere are made by large groups of engineers and designers.

As the company expands simply to handle the demands of the commission, the price quickly exceeds the reach of the people making proposals; these proposals commonly come from early-career aspiración, and no company so far has responded to the immense demand for small-scale experiments, quick repairs and upgrades, or the necessary audience-building that younger business leaders seek as a core piece in the up-and-coming economies.

Our company needs to raise money, so here's our approach;


Because as much business as possible should occur and be recorded on our domains, each decision is backed by a sample of code to help us comprehend the program being made.

Look! each code sample begins in nd; this is a simple alias used in place of nix develop --command. You can use the same alias in your shell, once you run:

alias nd="nix develop --command"

Our code under code/build has more guidance, and includes an enormous collección of code based on nushell. Using Elixir more directly? Drop the nd.

Memberships

"Usually" coders call people as "users"; in my opinion such a label holds some unnecessary sharp edges.

Seemingly more sensible than the customary "customer" used among other disciplines, the descripción of "user" is also commonly applied to people consuming occasionally-dangerous chemicals. Such an analogy becomes more concerning, the more you consider the implicacións applied to silicon.

In our case, "members" is good enough; I had originally modeled using the label "humans", and decided there are cases where companies also can be recognized as members.

Our code is in nushell,
so please combine each command on a single line in other shells.

( nd mix phx.gen.live Company Member members
  moniker:unique aliases:array:string:unique
  email:unique:redact passcode:redact )

Members can make and manage groups, a common concern in basically any modern online program.

( nd mix phx.gen.live Company Group groups
  moniker:unique labels:array:string )
( nd mix phx.gen.live Company Membership memberships
  member:references:members group:references:groups )

Permissions may end up being complex, and can be modeled once people describe their needs more precisely. No need to handle permissions today.

Money handling

Humans are quirky enough to apply numbers to nearly any physical idea. Super odd, yes. In business, such has ended up as a necessary rule.

By speaking among numerous bankers, and reading occasional legal codes concerning the mocións of monies, here are some simple shapes our program can use to help us pay-and-be-paid.

Many of these bankers are anxious around being scammed, probably because they experience the phenomenon a bunch. Our company should also aim to reduce illegal usage and please our bankers, by recording addresses used in many accións.

( nd mix phx.gen.live Company Address addresses
  member:references:members
  line_a line_b locale region nacion zip )

As all of us had seen in the company's early days, no payment is immediate - and in good, legal cases, each one requires negociación and agreement on both sides of the acción. Realizing these rules has helped us decide on the core mechanism of our payments pipeline: schedules.

( nd mix phx.gen.live Company Schedule schedules
  manager:references:members
  payee:references:members
  payor:references:members
  charge_card:string
  address:references:addresses
  enrolled:timestamp
  applied:timestamp
  engages:timestamp
  expires:timestamp
  recurrence:string )

I bring this up because nearly all the money and gear concerns from here on, all call back to the same basic schedule.

Such as the /chronicle has become our mode of publicación, the schedule shall become our company's ledger and balance.

Presumably, each schedule can depend on other schedules! I'm sure this shall cause no problems, zero issues.

( nd mix phx.gen.live Company Dependency dependencies
  source:references:schedules
  depends:references:schedules )

From here on, the remainder of money handling becomes simple-as-can-be; simply make sure any money-bound idea has a clear associación to a schedule.

This arrangement means people can begin sponsoring our programs:

( nd mix phx.gen.live Company Sponsorship sponsorships
  schedule:references:schedules
  price:int currency:string )

And someday soon our code should be able to charge them any necessary sums.

( nd mix phx.gen.live Company Charge charges
  schedule:references:schedules
  price:int currency:string
  enrolled:timestamp applied:timestamp )

Both such accións are recorded to a common schedule, meaning our book-keeping has become so much simpler here! In any case demanding reconciliación, there is likely only a need to consider a single schedule, and the included associacións.

Gear Handling

Our company is based on the idea of shared processing resources. As you may recall our plan is sharing much of our /gear, in a manner similar to a lending library.

The gear is easy enough to describe in a basic manner; the key being a link address to help people double-check on specs.

( nd mix phx.gen.live Company Gear gear
  make model produced:date labels:array:string address:string )

Heads-up!

The remainder of this sección has broken code; the :array:references: is unmanageable in our database schema. Repairs are coming, soon as we make up some intermediary models to hold the associacións in place.

As I learned by running a pandemic-era mailing library (mainly based on normal books), people become eager to place holds on your resources.

There is a chance that some of these holds can demand payment; such as insurance charges for damageable or precious supplies, or usage charges for consumable supplies. Hence, the linked schedule may someday manage pricing alongside chronology.

( nd mix phx.gen.live Company Hold holds
  schedule:references:schedules
  gear:array:references:gear
  price:int currency:string )

Any gear needs purchase (unless you recycle enough)!

( nd mix phx.gen.live Company Order orders
  schedule:references:schedules
  gear:array:references:gear
  code:string price:int currency:string )

Holds and orders both presumably imply gear needs to be shipped someplace.

( nd mix phx.gen.live Company Ship ships
  schedule:references:schedules
  gear:array:references:gear )

Commissions

Once all the background business processes are in place, our program should be ready to handle operación proposals. A group called a 'commission' is assigned to manage the operación.

( nd mix phx.gen.live Company Operacion operacions
  commission:references:group
  schedule:references:schedules
  labels:array:string
  summary:text body:text )

Again, each operación is required to be on a schedule, so sponsors can apply money backing each proposal.

Also, sponsors can choose unique sub-schedules regarding their payment, and each operación schedule is marked as depending on the sponsorship schedules. Hence, labor should only proceed once some benchmarks are reached and agreed upon.

So each sponsor can keep up on proceedings, published and running operacións are enabled to share records. These records can be pre-composed, and marked to publish on a chosen day and hour.

( nd mix phx.gen.live Company Record records
  composer:references:members
  clock:timestamp
  publish:timestamp
  summary:text body:text
  ops:references:operacion
  gear:references:gear )

Since many non-billing hours are going to be expended managing gear, records are also applicable to gear pages, and can describe any changes in how each piece of gear is being used.


The code is published here so you can remix any such ideas as needed in your company; begin by using Elixir and Phoenix. Please also see phx.gen opcións.

← Chronicle