DEV Community: Jedidiah Weller 👑

Running Frontier AI Locally Still Doesn't Add Up

Jedidiah Weller 👑 — Mon, 02 Nov 2026 16:20:46 +0000

I wanted the answer to be “buy the hardware.”

Download an open-weight model. Run it on a machine you own. Stop watching a token meter. There is something deeply appealing about that, especially when AI becomes part of your daily development workflow.

But after digging into what it takes to run a large flagship model locally, I keep coming back to the same conclusion: for a developer or small team trying to replace demanding cloud AI workflows, buying local hardware usually doesn't make financial sense yet.

Useful local models absolutely exist. The expensive part is trying to preserve the capability, context, speed, and concurrency you actually rely on.

MindStudio's cost comparison helped frame the question. I wanted to push it further: beyond a desktop-versus-subscription comparison, what happens when you try to replace a team's API usage with a serious self-hosted endpoint?

Here is the math, with the assumptions visible.

The memory gap is bigger than the GPU shopping list suggests

GLM-5.2 is a useful case study. Unsloth's deployment guide describes a mixture-of-experts model with 744 billion total parameters and about 40 billion active per token. Z.ai's model card advertises a one-million-token context window. It is an example of a large flagship open model, rather than a claim that it is today's best model for every task.

That “40B active” number is easy to misread. It reduces the computation needed for each token; it doesn't turn the entire model into a 40B-parameter download. The other experts' weights still need to live somewhere. Offloading them to system RAM changes the memory and bandwidth tradeoff.

A rough lower-bound calculation is straightforward:

Weight storage = parameter count × bits per parameter ÷ 8

For 744 billion parameters:

Representation	Ideal weight storage
16-bit	1,488 GB
8-bit	744 GB
4-bit	372 GB

These are decimal GB and deliberately simplified figures. Real quantized formats include scales, metadata, and sometimes layers kept at higher precision. Runtime memory also needs room for working buffers and attention state.

For perspective, NVIDIA specifies 32 GB of VRAM for the RTX 5090. The idealized 4-bit weights alone are 11.6 times that capacity. Buying one excellent consumer GPU doesn't bridge this particular gap.

Unsloth lists roughly 372–475 GB for its 4-bit configurations and recommends spare memory beyond the model file size. That's the scale of the problem before a team starts sending requests.

High-memory desktops offer another route. Apple lists Mac Studio configurations with up to 512 GB of unified memory. That is a meaningful option for large local models, but memory capacity alone doesn't establish useful throughput, maximum usable context, or simultaneous-user capacity.

Getting it to load is only the first milestone

A model answering one prompt is a different accomplishment from a model serving your team throughout the day.

The serving system needs capacity for prompt processing, generated tokens, and the attention cache used while requests are in flight. Long contexts and concurrent requests compete for that capacity. vLLM's tuning guide documents the tradeoffs among cache space, concurrency, preemption, and throughput.

There's no honest universal rule that says “four GPUs equals production ready.” Architecture, quantization, serving software, prompt lengths, batching, and latency targets all matter.

I would also be careful with “4-bit is lossless.” A quantization evaluation can show close agreement under its test conditions. That doesn't guarantee identical behavior on a difficult refactor or a long tool-using task. The configuration you intend to deploy needs to pass your own workload evaluation.

The comparison I care about is cost per successfully completed task at an acceptable latency. A cheaper token can become an expensive task if it needs more retries or more human repair.

Renting the GPUs doesn't automatically solve the economics

First, separate three different purchases:

A managed model API: you pay for metered usage, subject to the provider's pricing and limits.
Rented GPUs: you operate the model on infrastructure billed for allocated time.
Owned hardware: you pay upfront and take responsibility for operating it.

An open-weight model can be served through any of these arrangements. Downloadable weights don't require you to become the hosting provider.

Consider an illustrative API budget of $1,000 per week, or $52,000 per year using 52 weeks. This is a scenario for the calculation, not a price quote for a particular token volume or model.

On November 2, 2026, Lambda's eight-GPU instance pricing lists H100 SXM at $3.99 per GPU-hour and B200 at $6.69 per GPU-hour, before applicable taxes.

For continuous allocation:

8 × $3.99 × 8,760 hours = $279,619/year for H100
8 × $6.69 × 8,760 hours = $468,835/year for B200

Those are approximately 5.4× and 9.0× the illustrative API budget, before your operating labor.

These are infrastructure price examples, not benchmark-equivalent replacements or minimum hardware recommendations. Other providers and commitments can change the rates. Turning a node off saves money, but also changes availability and adds startup considerations.

Even at a hypothetical $18 per hour for the entire node, continuous rental would cost $157,680 per year. A cheap hourly price can still become an expensive always-on service.

The payback calculation needs operating costs

Buying hardware sounds better because at least you eventually own it.

Let's use $300,000 upfront and $20,000 per year in operating costs as an illustrative server scenario. These are modeling assumptions, not a vendor quote or the entry price for all local AI. A high-memory workstation could cost much less and may suit one person; it needs its own quality and speed evaluation. A workstation that meets the same requirements could reverse the conclusion; the numbers need to follow the benchmark. For this team-server scenario, replace the figures with a real bill of materials and your own power, cooling, hosting, and support estimates.

Assume it completely replaces that $52,000 annual API spend:

Annual savings = $52,000 − $20,000 = $32,000
Simple payback = $300,000 ÷ $32,000 = 9.4 years

Dividing the purchase price by the API bill alone gives 5.8 years. That calculation quietly assumes the server costs nothing to operate.

Here is the same comparison in numbers:

Scenario	Three-year cash outlay
API at $1,000/week	$156,000
Owned server: $300k upfront + $20k/year	$360,000
Eight rented H100s, continuously allocated	$838,858

This simplified comparison holds rates and usage constant, ignores tax, financing and resale, and excludes engineering labor. It does not establish equal performance between the options. The owned-server case also assumes no replacement purchase or residual API bill during the period.

To recover that $300,000 purchase within three years, with $20,000 annual operations, you would need to displace $120,000 of API spending per year, or about $2,308 per week. You would also need enough serving capacity to handle that workload.

Labor can move the threshold again. Just four hours a week valued at $100 an hour adds $20,800 per year. Under the original $52,000 scenario, annual savings would fall to $11,200 and simple payback would stretch to 26.8 years. That isn't a forecast of hardware life; it is a sign that this set of assumptions fails the purchase test.

If annual operations and labor equal or exceed the API spending you actually eliminate, there is no simple financial payback.

Utilization is where the argument lives or dies

An API bill follows billable usage. An owned server ties up capital during nights, weekends, and quiet periods too.

A heavily utilized deployment can spread fixed costs across more completed work. A lightly used machine can't. But “keep it busy” isn't enough: extra tokens only create savings if they replace work you would otherwise pay for.

This is why I would measure a representative week before buying anything: completed tasks, input and output volume, latency, peak concurrency, failures, and time spent correcting results. Then I would benchmark the proposed local setup against those same tasks.

A consumer subscription, metered API access, and a dedicated endpoint also have different limits and operating terms. Their sticker prices aren't interchangeable measures of capacity.

There are good reasons to run locally

Some of them can outweigh a disappointing spreadsheet:

You need offline operation or strict control over where data is processed.
A smaller model already passes a narrow, valuable workload.
You already own suitable hardware and are evaluating the incremental cost.
You have predictable volume, high utilization, and the expertise to operate the service.
Learning, experimentation, or independence is part of what you're buying.

Those are legitimate objectives. A local model doesn't have to match every flagship cloud model to be useful or economical.

For many teams, a hybrid approach deserves consideration: use smaller local models for tasks they handle reliably and reserve expensive remote inference for work that needs it. Measure whether the added routing and maintenance are worth the savings.

What would change my mind?

I expect to revisit this. More capable small models, better quantization, faster memory, and cheaper high-memory hardware could all improve the local proposition.

But I wouldn't build a purchase decision around a promise that hardware prices must fall on a particular schedule. Cloud model prices and capabilities can improve too. The target keeps moving.

Before committing six figures, I would first test whether a less expensive managed model can meet the same acceptance criteria, remove unnecessary context, and measure any caching or batching discounts available for the workload. Those changes can reduce spending without adding a server to maintain.

I still want the machine-on-my-desk version to win. For a lot of focused tasks, it already can.

For replacing demanding, general-purpose AI work across a small team, though, the combination of memory, throughput, utilization, and upkeep remains difficult to justify. Today, I'm more interested in buying useful results than owning the hardware that generates them.

Research and listed prices checked November 2, 2026. Charts are original calculations, not hardware performance measurements. Start with the linked primary sources and substitute your own workload and quotes before making a purchase.

How We Cut 80 % of Our Backend Calls in Summon Worlds

Jedidiah Weller 👑 — Fri, 01 Aug 2025 17:40:00 +0000

TL;DR

Reduce redundant API calls by centralizing loading logic in a shared helper.
Always expose a domain model (class instance) instead of raw state slices.
Cache with shareReplay so multiple subscribers share one request.
Dispatch only plain-object payloads—no class instances in actions.
Inspired by our experience in the Summon Worlds AI world-building app.

0. The Backstory 🏗️

First things first - a story. In September of last year, we took over an AI World Building App called Summon Worlds. The app was a cool idea, had an great community, and scratched that gaming itch that all developers have.

So after we took it on, we rebuilt the (very hacky) flutter prototype in Ionic + Angular, and we decided to use NGRX to help with performance and storage calls. Since we were in a hurry, that was about all the thought we put into the pattern in which we were implementing NGRX and we thought it would be an easy process.

It was not.

So, fast forward till today - there were a ton of architecture and pattern decisions that I wish we did differently, and I'd like to share some of them with you so that hopefully you do not make the same mistakes as we did.

This particular article is focused on an "accidental" antipattern of NGRX + Clone Deep that caused major issues. If you like it let me know, and I'll write a couple more about some other anti-patterns to avoid!

1. How We Discovered The Antipattern 🏗️

The State was managed via NgRx and persisted to Firebase. One morning we noticed our billing spike—and Cloud Functions logs revealed that loading our simple “feed” screen fired 42 loadEntity calls every time. On slower networks, users waited ages. We knew something had to change.

2. Recognizing the Anti-Pattern

2.1 The Over-eager Helper

A common helper service looked like this:

@Injectable({ providedIn: 'root' })
export class GenericHelperService {
  constructor(private store: Store<AppState>) {}

  // Raw state slice used everywhere
  getEntityState$(): Observable<EntityState> {
    return this.store.select(selectEntityState);
  }

  // Lightweight shortcut mapping to a class
  getEntity$(): Observable<EntityModel> {
    return this.store.select(selectEntityData).pipe(
      map(data => new EntityModel(data))
    );
  }

  // Dispatching class instances directly
  updateEntity(model: EntityModel) {
    this.store.dispatch(updateEntity({ payload: model }));
  }
}

Every component calling getEntity$() would dispatch loadEntity again and again, re-instantiate the model, and violate NgRx’s serialization rules.

3. Core Principles of the Fix

Raw slice only for edge cases.
Instantiate your domain model exactly once in a shared helper.
Dispatch only plain JSON payloads—no class instances in actions.

These principles rescued our performance in Summon Worlds and will help any NgRx project.

4. A Generic Refactor Recipe

4.1 Strengthen the Helper

@Injectable({ providedIn: 'root' })
export class GenericHelperService {
  constructor(private store: Store<AppState>) {}

  /** Raw slice — cache and reuse sparingly */
  getEntityState$(): Observable<EntityState> {
    return this.store.select(selectEntityState).pipe(
      shareReplay(1)
    );
  }

  /** Central loader + model emitter */
  getEntity$(id: string): Observable<EntityModel> {
    // Trigger load exactly once per id
    this.store.dispatch(loadEntity({ id }));

    return combineLatest([
      this.store.select(selectEntityById(id)),
      this.store.select(selectEntityLoading(id))
    ]).pipe(
      filter(([data, loading]) => !!data && !loading),
      map(([data]) => new EntityModel(data)),
      shareReplay({ bufferSize: 1, refCount: true })
    );
  }

  /** Mutations accept model, dispatch plain data */
  saveChanges(model: EntityModel): void {
    const payload = model.toPlainObject();
    this.store.dispatch(updateEntity({ payload }));
  }
}

shareReplay(1) shares one subscription, caching the latest value.
combineLatest + filter waits until data is ready before emitting.
toPlainObject() strips methods, leaving a serializable payload.

4.2 Use the Async Pipe Everywhere

Before (Summon Worlds style):

ngOnInit() {
  this.sub = this.helper.getEntity$(id)
    .subscribe(model => this.value = model.compute());
}
ngOnDestroy() { this.sub.unsubscribe(); }

After:

value$ = this.helper.getEntity$(id).pipe(
  map(model => model.compute())
);

<div>{{ value$ | async }}</div>

No manual subscriptions, no memory leaks, no boilerplate.

4.3 Remove Deep-Clone Workarounds

Swap out:

const safeData = cloneDeep(rawData)!;

For:

computed$ = this.helper.getEntity$(id).pipe(
  map(model => model.optionalProp ?? defaultValue)
);

TypeScript strict checks catch missing properties, eliminating the cloneDeep band-aid.

4.4 Centralize Error Handling

Instead of catching errors in every component:

this.helper.getEntity$(id).pipe(
  catchError(err => {
    console.error(err);
    return of(null);
  })
);

Handle failures in an effect:

loadEntityFailure$ = createEffect(() =>
  this.actions$.pipe(
    ofType(loadEntityFailure),
    tap(({ error }) => this.toast.error(`Load failed: ${error}`))
  ), { dispatch: false }
);

Your components only worry about rendering the happy path.

5. Migration Checklist

Helper overhaul

Add shareReplay on raw-slice methods.
Implement getEntity$() with load dispatch, combineLatest, filter, mapping, and shareReplay.
1. Component cleanup
Replace manual subscriptions with async-pipe streams.
1. Payload serialization
Add .toPlainObject() to your models.
Dispatch only JSON in actions.
1. Remove cloneDeep
Delete all deep-clone code.
1. Centralize error flow
Catch errors in effects only.
1. Enable runtime checks

   StoreModule.forRoot(reducers, {
     runtimeChecks: {
       strictStateImmutability: true,
       strictActionImmutability: true,
     }
   })

6. Measuring Success

Metric	Before	After	Improvement
Backend calls per view	42	4	−90%
Memory on initial render (MB)	28	18	−36%
Time to first paint (s)	4.2	2.7	−1.5

(These are some of the actual numbers we achieved, fyi)

7. FAQs

Q: Why not dispatch class instances?
A: They break DevTools serialization, effect replay, and cross-tab sync. POJOs are the safest contract.

Q: Aren’t selectors memoized?
A: Yes—but extra loadEntity dispatches before data arrives bypass selector caching. shareReplay fixes that gap.

8. Generic Snippets to Copy

Model Skeleton

export class EntityModel {
  constructor(private data: EntityData) {}
  get id(): string { return this.data.id; }
  compute(): number { /* domain logic */ return 0; }
  toPlainObject(): EntityData { return { ...this.data }; }
}

Helper Skeleton

@Injectable({ providedIn: 'root' })
export class GenericHelperService {
  constructor(private store: Store<AppState>) {}
  getEntity$(id: string): Observable<EntityModel> {
    this.store.dispatch(loadEntity({ id }));
    return combineLatest([
      this.store.select(selectEntityById(id)),
      this.store.select(selectEntityLoading(id))
    ]).pipe(
      filter(([data, loading]) => !!data && !loading),
      map(([data]) => new EntityModel(data)),
      shareReplay({ bufferSize: 1, refCount: true })
    );
  }
}

9. Next Steps

Measure your own before/after metrics.
Refactor one entity at a time.
Share this guide and (of course) check out Summon Worlds if you are into AI world-building.

Happy refactoring—and may your selectors be ever memoized!

What to Do After the Coding Academy

Jedidiah Weller 👑 — Wed, 19 Dec 2018 20:46:34 +0000

Introduction - What to Do After The Coding Academy
Step 1 - Learn The True Fundamentals
Step 2 - Create a very simple C++ application
Step 3 - Translate that C++ Application into a Web Application
Step 4 - Understand the Internet
Step 5 - Understand your environment
Step 6 - Go HAM on a Web Dev Framework - but be well-rounded too
Step 7 - Practice Being Systematic
Closing Remarks

What to Do After The Coding Academy

Hello everyone! For about 5 years now I've owned and operated a development shop, and in that time I have had the privilege of seeing many developers grow their skills (both professionally and personally) as they entered the workplace. However; I quickly noticed some trends from individuals coming from Coding Academies and Bootcamps.

While teaching our young padawans, I quickly learned that there is a lot of information missing from most Coding Academy curriculums. I chalk it up to the programs being so short and attempting to cram so much knowledge into their brains at a time. Most people gain the knowledge of "what is" software development, but lack the wisdom of "how to" use it.

If this is you (or one of your team members) - you're not alone. It's nearly impossible to become a full-fledged software engineer in 3-6 months, although places like NYDCA would like you to believe otherwise. And perhaps that is why they shut down. But fear not; there is hope! Coding Academies are a great start to your journey so long as they are followed by the right mentorship and guidance on where to go next.

So, I'd like to provide exactly that - mentorship and guidance on "What to do next". I hope this article will graduates, as well as Senior Devs and Managers out there tasked with training them. We're all in this career together, so let's help each other make it an amazing one for everyone.

P.S. If anyone has additional items you think are useful; I'll update this article to be a culmination of best practices/wisdom.

Step 1 - Learn The True Fundamentals

You may have thought you learned the fundamentals at your coding academy; but alas you actually learned the fundamentals of web development. What you did not yet learn is the fundamentals of the "how" and "why" of computer science. Questions like "What is an IP address?", "What is a var (under the hood)?", and "How can I step-through debug this problem?" are never asked nor taught, so it's up to us to fix that.

To get this understanding I'd recommend traveling to the past so that you can understand the future. Scripting languages are NOT the place to learn fundamentals; however, C++ is built on the fundamentals. You'll probably never use this language again - but I DO want you to take 2-3 days to go through the following tutorials. I promise they'll be beneficial - so here's the steps

Download Visual Studio Code
Take yourself through this C++ tutorial
Complete chapters 0, 1, 2, 4, 5, 6, 7:
While completing the Chapters answer the following questions:
- What did you learn from this chapter?
- What questions/difficulties did you have during the chapter?
- What questions or things do you want to try, at the end of the chapter?

Step 2 - Create a very simple C++ application.

I'd recommend the following:

Create an application that

When launched via the command line, says "Hello, what would you like to create? "1: A Dog", "2: A Cat""
When the user types "1" and hits enter, a Dog class is created.
In the Dog Class Constructor, have a print function "I am a dog, I am born"
In the Cat Class Constructor, have a print function "I am a cat, I am born!"
Abstract Dog and Cat class to be part of an Animal class, and inherit from it.
Complete some other small changes to reflect what you've just learned in your tutorials

Step 3 - Translate that C++ Application into a Web Application.

Now, create a Web Application using the technology you've been taught at your coding academy - but instead of the command line, have a GUI through a web browser. Either an Angular Application or a Rails Application will do just fine, then answer the following questions:

How does C++ compare to javascript/ruby?
What are the differences?
Which parts were easier? Which parts were harder?
Have a friend introduce an error in both - but not show you where. Now, try to debug the error on both. Do you see a difference in debugging?

Step 4 - Understand the Internet.

Most people don't understand what the internet actually is; and it's truly magic.
Did you know there is all this hidden data in every packet that's sent over the web? Do you know how your ISP works? Well, to get started let's read this Stanford whitepaper on what the Internet actually is.

Step 5 - Understand your environment.

This step is a controversial step and is best done on an old crappy computer you don't use anymore. If you don't have one - make sure to back everything up on your current system.

(Assuming you're creating an Angular App) Download and install Homebrew, Node, NPM, Bower, and Grunt.
Try to install and run A MEAN Stack sample app
Uninstall the current version of node, and install an older version. Play with versioning through NVM
Try to run the same app.
Now, do the same thing on someone else's computer. Doesn't matter what type - there's learning on all OS :)

You may or may not have issues - guess what; version dependencies are a BIG BIG challenge for a lot of developers. 5 people with macs may all have different environments - and that's not even including all the variations of Windows / Windows + Ubuntu / Linux distros.

(Bonus) Wipe your computer - and re-install everything. That's the controversial part, but often when you're doing development and you don't quite understand filepaths and chmod/sudo consequences you'll mess up your dev environment. You can spend hours debugging it, or you can wipe and restart - your choice.

Now, you must be thinking to yourself "There's got to be a way to standardize environments". Yes, there are plenty of ways. A well-known approach is a tool called Docker. I'll let you read up on the rest.

Step 6 - Go HAM on a Web Dev Framework - but be well-rounded too

I personally love the Angular + Ionic combination for Web & Mobile apps, but there are a ton out there. React.js is awesome and I'll be at the Vue.js conference in Amsterdam in February. Once our interns at OpenForge are done with the above steps (and some 1-1 sessions), we ask them to start completing some online courses through Udemy.

First, I'd take a quick debugging class here to learn about Chrome dev tools
Second, complete the entirety of this Angular 7 course. It covers a LOT
Third, take appreciation for my array numbering to the left <-- If you know your basics, you know why I did this :)
Fourth, practice creating a MEAN stack app and deploying it. Here's some links
http://www.hongkiat.com/blog/node-js-server-side-javascript/
https://devcenter.heroku.com/articles/mean-apps-restful-api
http://blog.modulus.io/build-your-first-http-server-in-nodejs

Step 7 - Practice Being Systematic

PAY ATTENTION TO THIS - This is the most important piece of advice I can give you.

When you're working on a feature, debugging, or any type of development - commit after every meaningful change. Do NOT wait for the feature/bug to be finished.

Computer Science is a science, and science is systematic. We try, measure, and come to conclusions. I promise you that if you break down large commits and large problems into super small ones; you will accomplish tasks 10x quicker and be happier for it.

Closing Remarks

I hope this is helpful - it's been the 'time-tested mother-approved' formula for us for a couple years now.

If anyone has anything else to add (or recommends modifications) I am all ears, please comment below!

Best Regards,
www.twitter.com/jedihacks

Passion Projects are Fun - Except In Production

Jedidiah Weller 👑 — Sun, 25 Nov 2018 15:45:55 +0000

Right around the time that the Ionic team came out with Stencil.js our company made a brand transition from Webjunto to OpenForge. Since we are all massively in love with all things technology; we said "OMG - An opportunity to play with Stencil! Let's build our Website using Stencil as a web-component pre-compiler and scratch that Wordpress B.S. It will be so much faster!".

From a business owner's perspective, it was a perfect opportunity to transition from Wordpress to something that we built with our own hands. We could Open Source and talk about it. It allowed us to train our team on a new technology while simultaneously applying it to something useful.

But - we were unprepared. That's when the pain hit.

Our Assumption

We drastically underestimated how much is truly built into Wordpress that we never think about. Between Blog, Page, User Management, and SEO capabilities - it's a huge set of features, and eliminates a lot of need for process internally in the team between the design, dev, and business departments.

We also assumed that anything that was in Wordpress we could easily build, and to our team's credit we can build the features; however - what we don't have is the process for identifying what needs to be reviewed across departments.

For instance; how many business people think about the manifest.json file? How many people (in a full design & dev team) are qualified to identify SEO mismatches between content and url routing? These things are automatically provided and identified by Wordpress and Yoast, and we didn't even realize it.

The benefit was that it created a need to more tightly integrate the 3 major departments at our company (Design, Dev, Business); however, the down side was that we had to create a process for this and we were completely unprepared.

My Advice

Was it worth it? I think so due to the training to the team, PWA expertise, and lessons learned; however, on a scale of 'how worth it' it was not as clearly a win as I expected.

I'll break down my advice into a bulleted list of what was worth it, and what pieces we missed. My hope is if you would like to try the same thing for your company, you'll have a bit of a headstart on what troubles may arise.

Worth It

The experience & training (as we move into single-source PWA's)
The speed (It feels like the road-runner compared to WP)
The control (fully customizable, without any plugin development)

Harder Than Expected / Unexpected

SEO Management. What's the replacement for Yoast?
- Robots.txt
- Manifest File
- URL Routing Strategy (and who reviews this?)
- 404 Page for old I.E. (we just redirect)
- Canonical Links
- Alt Text to images (we keep forgetting - need to update process)
Polyfills
Lighthouse Optimizations (local vs. deployed)
Smooth Scrolling
Accessibility

There were some more items that didn't make it into our changelog, as I think of them I'll update the post.

Hope this helps folks!

~Jedi

Tutorial 1,000 - A Real Production App

Jedidiah Weller 👑 — Wed, 24 Oct 2018 14:25:42 +0000

Hey everyone,

Yesterday we released (and open-sourced) a full production mobile app, and wrote a guest blog about it through Ionic's Blog. It's not everyday we get to see the 'nuts-and-bolts' of a full app, so I figured I'd share it with the community here as well :)

It took around 400 hours to design and build the Ionic 3 app. We used a serverless architecture, Firebase, and Ionic 3.

Why we built it

We're developers - although we always scope work the scoping process can get messy.

It's very easy to be 'peer pressured' (even unknowingly) into changing your estimates when your friends and colleagues think differently. This is exacerbated when you have junior and senior developers in the same room providing estimates together. The junior devs are often afraid to provide real estimates, because they are much longer than the senior's.

We used to use planningpoker.com for scoping sessions; but everyone could see each others estimates and then during a session team members would change their answers to avoid confrontation. This often leads to inaccurate scopes; because the person who's answer wins is not always the person tasked with completing the work.

Why we open-sourced it

It's aggravatingly difficult to find examples of real production applications that are open sourced (but still simple to follow). When I train new team members, I find that going from Angular's "tutorial 101" to building a full application is about a 10 foot step, and no one has 10 foot legs.

So, when the dev team proposed designing and building this tool we agreed to open source it and write about it. It's got some cool features, such as

Teamwork Projects integration
Serverless architecture
Ionic 3 application
Live scoping via Firebase
Firebase. Firebase. Firebase. We're loving Firebase :D

We wrote a full guest blog post about the architecture and decisions we made on Ionic's Blog, so rather than re-invent the wheel I'd encourage everyone to read the full breakdown there.

Should you download it?

No - you should Clone it from Github and use it yourself. However; we figured it may be hard to get some project managers on board if it didn't have a least a semblance of an established app. So go ahead, use it if you'd like, but seriously - feel free to take it as well :)

Next Steps

We had a lot of positive feedback from the product; so we'll be releasing another full production app next month (open sourced) and blogging about the process. We don't intend to build any more integrations besides Teamwork because that's what we use internally at OpenForge.io; however, if you are using another tool and would like to create a PR we'd be happy to help support it.

Thanks everyone, stay cool and dev on!

Jedi